From 07d90b6fe4c382acdbbd50bd929f76b8bb7fa0ca Mon Sep 17 00:00:00 2001 From: teastep Date: Mon, 21 Jul 2003 22:06:18 +0000 Subject: [PATCH] Shorewall-1.4.6 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@672 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Lrp/etc/shorewall/hosts | 3 +- Lrp/etc/shorewall/interfaces | 14 + Lrp/etc/shorewall/masq | 13 +- Lrp/etc/shorewall/rules | 18 +- Lrp/etc/shorewall/shorewall.conf | 61 +- Lrp/sbin/shorewall | 72 +- Lrp/usr/share/shorewall/firewall | 472 +- Lrp/usr/share/shorewall/functions | 191 +- Lrp/usr/share/shorewall/version | 2 +- Lrp/var/lib/lrpkg/shorwall.version | 2 +- STABLE/changelog.txt | 60 +- STABLE/documentation/6to4.htm | 207 +- STABLE/documentation/Documentation.htm | 5618 +++++++++-------- STABLE/documentation/ECN.html | 138 +- STABLE/documentation/FAQ.htm | 2420 +++---- STABLE/documentation/Forum.html | 43 +- STABLE/documentation/GnuCopyright.htm | 571 +- STABLE/documentation/IPIP.htm | 385 +- STABLE/documentation/IPSEC.htm | 1382 ++-- STABLE/documentation/Install.htm | 323 +- STABLE/documentation/MAC_Validation.html | 176 +- STABLE/documentation/NAT.htm | 192 +- STABLE/documentation/News.htm | 5566 +++++++++------- STABLE/documentation/OPENVPN.html | 457 +- STABLE/documentation/PPTP.htm | 1754 ++--- STABLE/documentation/ProxyARP.htm | 278 +- STABLE/documentation/SeattleInTheSpring.html | 57 +- STABLE/documentation/Shorewall_CA_html.html | 122 +- .../documentation/Shorewall_CVS_Access.html | 63 +- .../documentation/Shorewall_Squid_Usage.html | 991 +-- .../Shorewall_and_Aliased_Interfaces.html | 1176 ++-- .../documentation/Shorewall_index_frame.htm | 205 +- .../documentation/Shorewall_sfindex_frame.htm | 200 +- STABLE/documentation/VPN.htm | 152 +- STABLE/documentation/blacklisting_support.htm | 104 +- .../configuration_file_basics.htm | 622 +- STABLE/documentation/copyright.htm | 51 +- STABLE/documentation/dhcp.htm | 105 +- STABLE/documentation/download.htm | 294 +- STABLE/documentation/errata.htm | 537 +- STABLE/documentation/errata_1.htm | 381 +- STABLE/documentation/errata_2.htm | 842 ++- STABLE/documentation/errata_3.html | 995 ++- STABLE/documentation/fallback.htm | 129 +- STABLE/documentation/gnu_mailman.htm | 99 +- STABLE/documentation/kernel.htm | 291 +- STABLE/documentation/mailing_list.htm | 335 +- STABLE/documentation/myfiles.htm | 341 +- STABLE/documentation/ping.html | 341 +- STABLE/documentation/ports.htm | 346 +- STABLE/documentation/quotes.htm | 155 +- STABLE/documentation/samba.htm | 200 +- .../documentation/seattlefirewall_index.htm | 812 ++- STABLE/documentation/shoreline.htm | 159 +- .../shorewall_extension_scripts.htm | 196 +- STABLE/documentation/shorewall_features.htm | 147 +- .../shorewall_firewall_structure.htm | 504 +- STABLE/documentation/shorewall_logging.html | 226 +- STABLE/documentation/shorewall_mirrors.htm | 134 +- .../documentation/shorewall_prerequisites.htm | 99 +- .../shorewall_quickstart_guide.htm | 581 +- .../documentation/shorewall_setup_guide.htm | 4776 +++++++------- STABLE/documentation/sourceforge_index.htm | 836 ++- STABLE/documentation/standalone.htm | 650 +- STABLE/documentation/standalone_fr.html | 786 +-- .../starting_and_stopping_shorewall.htm | 515 +- STABLE/documentation/support.htm | 491 +- STABLE/documentation/three-interface.htm | 2028 +++--- STABLE/documentation/three-interface_fr.html | 2087 +++--- STABLE/documentation/traffic_shaping.htm | 534 +- STABLE/documentation/troubleshoot.htm | 338 +- STABLE/documentation/two-interface.htm | 1700 ++--- STABLE/documentation/two-interface_fr.html | 2055 +++--- STABLE/documentation/upgrade_issues.htm | 762 +-- STABLE/documentation/useful_links.html | 59 +- .../whitelisting_under_shorewall.htm | 573 +- STABLE/fallback.sh | 2 +- STABLE/firewall | 10 +- STABLE/functions | 161 + STABLE/hosts | 3 +- STABLE/install.sh | 2 +- STABLE/interfaces | 14 + STABLE/masq | 13 +- STABLE/releasenotes.txt | 181 +- STABLE/rules | 18 +- STABLE/shorewall | 72 +- STABLE/shorewall.conf | 53 +- STABLE/shorewall.spec | 10 +- STABLE/uninstall.sh | 2 +- 89 files changed, 26968 insertions(+), 24173 deletions(-) diff --git a/Lrp/etc/shorewall/hosts b/Lrp/etc/shorewall/hosts index c38ae4a2e..a60b16bee 100644 --- a/Lrp/etc/shorewall/hosts +++ b/Lrp/etc/shorewall/hosts @@ -20,7 +20,7 @@ # ZONE - The name of a zone defined in /etc/shorewall/zones # # HOST(S) - The name of an interface followed by a colon (":") and -# either: +# a comma-separated list whose elements are either: # # a) The IP address of a host # b) A subnetwork in the form @@ -33,6 +33,7 @@ # # eth1:192.168.1.3 # eth2:192.168.2.0/24 +# eth3:192.168.2.0/24,192.168.3.1 # # OPTIONS - A comma-separated list of options. Currently-defined # options are: diff --git a/Lrp/etc/shorewall/interfaces b/Lrp/etc/shorewall/interfaces index cfc0e2b0e..41c50e807 100644 --- a/Lrp/etc/shorewall/interfaces +++ b/Lrp/etc/shorewall/interfaces @@ -20,6 +20,10 @@ # an alias (e.g., eth0:0) here; see # http://www.shorewall.net/FAQ.htm#faq18 # +# You may specify wildcards here. For example, if you +# want to make an entry that applies to all PPP +# interfaces, use 'ppp+'. +# # DO NOT DEFINE THE LOOPBACK INTERFACE (lo) IN THIS FILE. # # BROADCAST The broadcast address for the subnetwork to which the @@ -89,6 +93,16 @@ # sub-networking as described at: # http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet # +# newnotsyn - TCP packets that don't have the SYN +# flag set and which are not part of an +# established connection will be accepted +# from this interface, even if +# NEWNOTSYN=No has been specified in +# /etc/shorewall/shorewall.conf. +# +# This option has no effect if +# NEWNOTSYN=Yes. +# # The order in which you list the options is not # significant but the list should have no embedded white # space. diff --git a/Lrp/etc/shorewall/masq b/Lrp/etc/shorewall/masq index 27826945c..c127c2ac8 100644 --- a/Lrp/etc/shorewall/masq +++ b/Lrp/etc/shorewall/masq @@ -42,12 +42,15 @@ # will automatically add this address to the # INTERFACE named in the first column. # -# WARNING: Do NOT specify ADD_SNAT_ALIASES=Yes if -# the address given in this column is the primary -# IP address for the interface in the INTERFACE -# column. +# You may also specify a range of up to 256 +# IP addresses if you want the SNAT address to +# be assigned from that range in a round-robin +# range by connection. The range is specified by +# -. # -# This column may not contain a DNS Name. +# Example: 206.124.146.177-206.124.146.180 +# +# This column may not contain DNS Names. # # Example 1: # diff --git a/Lrp/etc/shorewall/rules b/Lrp/etc/shorewall/rules index 5cc3c328e..b633c904b 100644 --- a/Lrp/etc/shorewall/rules +++ b/Lrp/etc/shorewall/rules @@ -107,6 +107,12 @@ # 3. You may not specify both an interface and # an address. # +# Unlike in the SOURCE column, you may specify a range of +# up to 256 IP addresses using the syntax +# -. When the ACTION is DNAT or DNAT-, +# the connections will be assigned to addresses in the +# range in a round-robin fashion. +# # The port that the server is listening on may be # included and separated from the server's IP address by # ":". If omitted, the firewall will not modifiy the @@ -137,7 +143,7 @@ # In that case, it is suggested that this field contain # "-" # -# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then +# If your kernel contains multi-port match support, then # only a single Netfilter rule will be generated if in # this list and the CLIENT PORT(S) list below: # 1. There are 15 or less ports listed. @@ -154,7 +160,7 @@ # specify an ADDRESS in the next column, then place "-" # in this column. # -# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then +# If your kernel contains multi-port match support, then # only a single Netfilter rule will be generated if in # this list and the DEST PORT(S) list above: # 1. There are 15 or less ports listed. @@ -214,6 +220,14 @@ # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # # PORT PORT(S) DEST # DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69 +# +# Example: You want to accept SSH connections to your firewall only +# from internet IP addresses 130.252.100.69 and 130.252.100.70 +# +# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL +# # PORT PORT(S) DEST +# ACCEPT net:130.252.100.69,130.252.100.70 \ +# tcp 22 ############################################################################## #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST diff --git a/Lrp/etc/shorewall/shorewall.conf b/Lrp/etc/shorewall/shorewall.conf index 8258f90ac..9e417baad 100644 --- a/Lrp/etc/shorewall/shorewall.conf +++ b/Lrp/etc/shorewall/shorewall.conf @@ -67,14 +67,14 @@ LOGFILE=/var/log/messages # # If you want to integrate Shorewall with fireparse, then set LOGFORMAT as: # -# LOGFORMAT="fp=%s:%d a=%s " +# LOGFORMAT="fp=%s:%d a=%s " # # If not specified or specified as empty (LOGFORMAT="") then the value # "Shorewall:%s:%s:" is assumed. -# -# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up +# +# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up # to but not including the first '%') to find log messages in the 'show log', -# 'status' and 'hits' commands. This part should not be omitted (the +# 'status' and 'hits' commands. This part should not be omitted (the # LOGFORMAT should not begin with "%") and the leading part should be # sufficiently unique for /sbin/shorewall to identify Shorewall messages. @@ -144,7 +144,7 @@ BLACKLIST_LOGLEVEL= # Example: LOGNEWNOTSYN=debug -LOGNEWNOTSYN= +LOGNEWNOTSYN=info # # MAC List Log Level @@ -191,6 +191,14 @@ RFC1918_LOG_LEVEL=info # PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin +# +# SHELL +# +# The firewall script is normally interpreted by /bin/sh. If you wish to change +# the shell used to interpret that script, specify the shell here. + +SHOREWALL_SHELL=/bin/sh + # SUBSYSTEM LOCK FILE # # Set this to the name of the lock file expected by your init scripts. For @@ -230,24 +238,6 @@ MODULESDIR= # FW=fw -# -# ENABLE NAT SUPPORT -# -# You probally want yes here. Only gateways not doing NAT in any form, like -# SNAT,DNAT masquerading, port forwading etc. should say "no" here. -# -NAT_ENABLED=Yes - -# -# ENABLE MANGLE SUPPORT -# -# If you say "no" here, Shorewall will ignore the /etc/shorewall/tos file -# and will not initialize the mangle table when starting or stopping -# your firewall. You must enable mangling if you want Traffic Shaping -# (see TC_ENABLED below). -# -MANGLE_ENABLED=Yes - # # ENABLE IP FORWARDING # @@ -378,26 +368,6 @@ ROUTE_FILTER=No NAT_BEFORE_RULES=Yes -# MULTIPORT support -# -# If your kernel includes the multiport match option -# (CONFIG_IP_NF_MATCH_MULTIPORT), you may enable it's use here. When this -# option is enabled by setting it's value to "Yes" or "yes": -# -# 1) If you list more that 15 ports in a comma-seperated list in -# /etc/shorewall/rules, Shorewall will not use the multiport option -# but will generate a separate rule for each element of each port -# list. -# 2) If you include a port range (:) in the -# rule, Shorewall will not use the multiport option but will generate -# a separate rule for each element of each port list. -# -# See the /etc/shorewall/rules file for additional information on this option. -# -# if this variable is not set or is set to the empty value, "No" is assumed. - -MULTIPORT=No - # DNAT IP ADDRESS DETECTION # # Normally when Shorewall encounters the following rule: @@ -447,7 +417,7 @@ MUTEX_TIMEOUT=60 # # NEWNOTSYN # -# If this variable is set to "No" or "no", then When a TCP packet that does +# If this variable is set to "No" or "no", then when a TCP packet that does # not have the SYN flag set and the ACK and RST flags clear then unless the # packet is part of an established connection, it will be dropped by the # firewall @@ -458,6 +428,9 @@ MUTEX_TIMEOUT=60 # Users with a High-availability setup with two firewall's and one acting # as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may # also need to select NEWNOTSYN=Yes. +# +# The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis +# using the 'newnotsyn' option in /etc/shorewall/interfaces. NEWNOTSYN=No diff --git a/Lrp/sbin/shorewall b/Lrp/sbin/shorewall index fa5555fa3..1817e16cd 100755 --- a/Lrp/sbin/shorewall +++ b/Lrp/sbin/shorewall @@ -82,6 +82,22 @@ # be automatically reinstated the # next time that Shorewall starts. # +# shorewall ipaddr [
/ |
] +# +# Displays information about the network +# defined by the argument[s] +# +# shorewall iprange
-
Decomposes a range of IP addresses into +# a list of network/host addresses. +# +# Fatal Error +# +fatal_error() # $@ = Message +{ + echo " $@" >&2 + exit 2 +} + # Display a chain if it exists # @@ -138,6 +154,13 @@ get_config() { [ -n "LOGFORMAT" ] && LOGFORMAT="${LOGFORMAT%%%*}" [ -n "$LOGFORMAT" ] || LOGFORMAT="Shorewall:" + + if [ -n "$SHOREWALL_SHELL" ]; then + if [ ! -e "$SHOREWALL_SHELL" ]; then + echo "The program specified in SHOREWALL_SHELL does not exist or is not executable" >&2 + exit 2 + fi + fi } # @@ -521,6 +544,8 @@ usage() # $1 = exit status echo " reject
..." echo " allow
..." echo " save" + echo " ipcalc [
/ |
]" + echo " iprange
-
" exit $1 } @@ -653,11 +678,13 @@ esac case "$1" in start|stop|restart|reset|clear|refresh|check) [ $# -ne 1 ] && usage 1 - exec $FIREWALL $debugging $nolock $1 + get_config + exec $SHOREWALL_SHELL $FIREWALL $debugging $nolock $1 ;; add|delete) [ $# -ne 3 ] && usage 1 - exec $FIREWALL $debugging $nolock $1 $2 $3 + get_config + exec $SHOREWALL_SHELL $FIREWALL $debugging $nolock $1 $2 $3 ;; show|list) [ $# -gt 2 ] && usage 1 @@ -860,7 +887,48 @@ case "$1" in fi mutex_off ;; + ipcalc) + if [ $# -eq 2 ]; then + address=${2%/*} + vlsm=${2#*/} + elif [ $# -eq 3 ]; then + address=$2 + vlsm=`ip_vlsm $3` + else + usage 1 + fi + + [ -z "$vlsm" ] && exit 2 + [ "x$address" = "x$vlsm" ] && usage 2 + [ $vlsm -gt 32 ] && echo "Invalid VLSM: /$vlsm" >&2 && exit 2 + + address=$address/$vlsm + + echo " CIDR=$address" + temp=`ip_netmask $address`; echo " NETMASK=`encodeaddr $temp`" + temp=`ip_network $address`; echo " NETWORK=$temp" + temp=`broadcastaddress $address`; echo " BROADCAST=$temp" + ;; + + iprange) + case $2 in + *.*.*.*-*.*.*.*) + ip_range $2 + ;; + *) + usage 1 + ;; + esac + ;; + call) + # + # Undocumented way to call functions in /usr/share/shorewall/functions directly + # + shift; + $@ + ;; *) usage 1 ;; + esac diff --git a/Lrp/usr/share/shorewall/firewall b/Lrp/usr/share/shorewall/firewall index 513d7b43c..61527c546 100755 --- a/Lrp/usr/share/shorewall/firewall +++ b/Lrp/usr/share/shorewall/firewall @@ -233,8 +233,7 @@ createchain() # $1 = chain name, $2 = If "yes", create default rules run_iptables -N $1 if [ $2 = yes ]; then - state="ESTABLISHED,RELATED" - run_iptables -A $1 -m state --state $state -j ACCEPT + run_iptables -A $1 -m state --state ESTABLISHED,RELATED -j ACCEPT [ -z "$NEWNOTSYN" ] && \ run_iptables -A $1 -m state --state NEW -p tcp ! --syn -j newnotsyn fi @@ -495,10 +494,17 @@ first_chains() #$1 = interface # find_hosts() # $1 = host zone { - local hosts + local hosts interface address addresses while read z hosts options; do - [ "x`expand $z`" = "x$1" ] && expandv hosts && echo `separate_list $hosts` + if [ "x`expand $z`" = "x$1" ]; then + expandv hosts + interface=${hosts%:*} + addresses=${hosts#*:} + for address in `separate_list $addresses`; do + echo $interface:$address + done + fi done < $TMP_DIR/hosts } @@ -608,7 +614,7 @@ validate_interfaces_file() { for option in $options; do case $option in - dhcp|norfc1918|tcpflags) + dhcp|norfc1918|tcpflags|newnotsyn) ;; routefilter|dropunclean|logunclean|blacklist|proxyarp|maclist|-) ;; @@ -636,18 +642,20 @@ validate_hosts_file() { r="$z $hosts $options" validate_zone $z || startup_error "Invalid zone ($z) in record \"$r\"" + interface=${hosts%:*} + + list_search $interface $all_interfaces || \ + startup_error "Unknown interface ($interface) in record \"$r\"" + + hosts=${hosts#*:} + for host in `separate_list $hosts`; do - interface=${host%:*} - - list_search $interface $all_interfaces || \ - startup_error "Unknown interface ($interface) in record \"$r\"" - for option in `separate_list $options`; do case $option in maclist|-) ;; routeback) - eval ${z}_routeback=\"$host \$${z}_routeback\" + eval ${z}_routeback=\"$interface:$host \$${z}_routeback\" ;; *) error_message "Warning: Invalid option ($option) in record \"$r\"" @@ -689,7 +697,7 @@ validate_policy() [ $1 = $2 ] || \ [ $1 = all ] || \ [ $2 = all ] || \ - echo " Policy for $1 to $2 is $policy" + echo " Policy for $1 to $2 is $policy using chain $chain" } all_policy_chains= @@ -832,6 +840,15 @@ find_interface_address() # $1 = interface echo $addr | sed 's/inet //;s/\/.*//;s/ peer.*//' } +# +# Find interface addresses--returns the set of addresses assigned to the passed +# device +# +find_interface_addresses() # $1 = interface +{ + ip addr show $1 | grep inet | sed 's/inet //;s/\/.*//;s/ peer.*//' +} + # # Find interfaces that have the passed option specified # @@ -848,10 +865,18 @@ find_interfaces_by_option() # $1 = option # find_hosts_by_option() # $1 = option { + local ignore hosts interface address addresses options + while read ignore hosts options; do expandv options - list_search $1 `separate_list $options` && \ - echo `expand $hosts` + if list_search $1 `separate_list $options`; then + expandv hosts + interface=${hosts%:*} + addresses=${hosts#*:} + for address in `separate_list $addresses`; do + echo $interface:$address + done + fi done < $TMP_DIR/hosts for interface in $all_interfaces; do @@ -1685,14 +1710,16 @@ check_config() { disclaimer() { echo - echo "WARNING: THE 'check' COMMAND IS TOTALLY UNSUPPORTED AND PROBLEM" - echo " REPORTS COMPLAINING ABOUT ERRORS THAT IT DIDN'T CATCH" - echo " WILL NOT BE ACCEPTED" + echo "Notice: The 'check' command is unsupported and problem" + echo " reports complaining about errors that it didn't catch" + echo " will not be accepted" echo } disclaimer + report_capabilities + echo "Verifying Configuration..." verify_os_version @@ -1839,7 +1866,11 @@ add_nat_rule() { if [ -n "$serv" ]; then servport="${servport:+:$servport}" - target1="DNAT --to-destination ${serv}${servport}" + serv1= + for srv in `separate_list $serv`; do + serv1="$serv1 --to-destination ${srv}${servport}" + done + target1="DNAT $serv1" else target1="REDIRECT --to-port $servport" fi @@ -1856,7 +1887,10 @@ add_nat_rule() { chain=nonat${nonat_seq} nonat_seq=$(($nonat_seq + 1)) createnatchain $chain - run_iptables -t nat -A OUTPUT $cli $proto $multiport $sports $dports -j $chain + + for adr in `separate_list $addr`; do + run_iptables2 -t nat -A OUTPUT $cli $proto $multiport $sports $dports -d $adr -j $chain + done for adr in $excludedests; do addnatrule $chain -d $adr -j RETURN @@ -1866,11 +1900,15 @@ add_nat_rule() { log_rule $loglevel $chain $logtarget -t nat fi - addnatrule $chain -j $target1 + addnatrule $chain $proto -j $target1 # Protocol is necessary for port redirection else for adr in `separate_list $addr`; do - run_iptables2 -t nat -A OUTPUT $proto $sports -d $adr \ - $multiport $dports -j $target1 + if [ -n "$loglevel" ]; then + log_rule $loglevel $OUTPUT $logtarget -t nat \ + `fix_bang $proto $cli $sports -d $adr $multiport $dports` + fi + + run_iptables2 -t nat -A OUTPUT $proto $sports -d $adr $multiport $dports -j $target1 done fi else @@ -1880,13 +1918,15 @@ add_nat_rule() { chain=nonat${nonat_seq} nonat_seq=$(($nonat_seq + 1)) createnatchain $chain - addnatrule `dnat_chain $source` $cli $proto $multiport $sports $dports -j $chain + + for adr in `separate_list $addr`; do + addnatrule `dnat_chain $source` $cli $proto $multiport $sports $dports -d $adr -j $chain + done + for z in $excludezones; do eval hosts=\$${z}_hosts for host in $hosts; do - for adr in `separate_list $addr`; do - addnatrule $chain -s ${host#*:} -d $adr -j RETURN - done + addnatrule $chain -s ${host#*:} -j RETURN done done @@ -1894,13 +1934,11 @@ add_nat_rule() { addnatrule $chain -d $adr -j RETURN done - for adr in `separate_list $addr`; do - if [ -n "$loglevel" ]; then - log_rule $loglevel $chain $logtarget -t nat -d `fix_bang $adr` - fi + if [ -n "$loglevel" ]; then + log_rule $loglevel $chain $logtarget -t nat + fi - addnatrule $chain -d $adr -j $target1 - done + addnatrule $chain $proto -j $target1 # Protocol is necessary for port redirection else for adr in `separate_list $addr`; do if [ -n "$loglevel" ]; then @@ -1943,6 +1981,8 @@ add_nat_rule() { done fi fi + + [ "x$addr" = "x0.0.0.0/0" ] && addr= } # @@ -2015,9 +2055,12 @@ add_a_rule() servport=$serverport multiport= + [ x$port = x- ] && port= + [ x$cport = x- ] && cport= + case $proto in tcp|udp|TCP|UDP|6|17) - if [ -n "$port" -a "x${port}" != "x-" ]; then + if [ -n "$port" ]; then dports="--dport" if [ -n "$multioption" -a "$port" != "${port%,*}" ]; then multiport="$multioption" @@ -2026,7 +2069,7 @@ add_a_rule() dports="$dports $port" fi - if [ -n "$cport" -a "x${cport}" != "x-" ]; then + if [ -n "$cport" ]; then sports="--sport" if [ -n "$multioption" -a "$cport" != "${cport%,*}" ]; then multiport="$multioption" @@ -2036,18 +2079,17 @@ add_a_rule() fi ;; icmp|ICMP|1) - [ -n "$port" ] && [ "x${port}" != "x-" ] && \ - dports="--icmp-type $port" + [ -n "$port" ] && dports="--icmp-type $port" state= ;; all|ALL) - [ -n "$port" ] && [ "x${port}" != "x-" ] && \ - fatal_error "Port number not allowed with \"all\"; rule: \"$rule\"" + [ -n "$port" ] && \ + fatal_error "Port number not allowed with protocol \"all\"; rule: \"$rule\"" proto= ;; *) state= - [ -n "$port" ] && [ "x${port}" != "x-" ] && \ + [ -n "$port" ] && \ fatal_error "Port number not allowed with protocol \"$proto\"; rule: \"$rule\"" ;; esac @@ -2098,15 +2140,39 @@ add_a_rule() fi if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then - serv="${serv:+-d $serv}" + if [ -n "$serv" ]; then + for serv1 in `separate_list $serv`; do + for srv in `ip_range $serv1`; do + if [ -n "$addr" -a -n "$CONNTRACK_MATCH" ]; then + for adr in `separate_list $addr`; do + if [ -n "$loglevel" -a -z "$natrule" ]; then + log_rule $loglevel $chain $logtarget -m conntrack --ctorigdst $adr \ + `fix_bang $proto $sports $multiport $state $cli -d $srv $dports` + fi - if [ -n "$loglevel" -a -z "$natrule" ]; then - log_rule $loglevel $chain $logtarget \ - `fix_bang $proto $sports $multiport $state $cli $serv $dports` + run_iptables2 -A $chain $proto $multiport $state $cli $sports \ + -d $srv $dports -m conntrack --ctorigdst $adr -j $target + done + else + if [ -n "$loglevel" -a -z "$natrule" ]; then + log_rule $loglevel $chain $logtarget \ + `fix_bang $proto $sports $multiport $state $cli -d $srv $dports` + fi + + run_iptables2 -A $chain $proto $multiport $state $cli $sports \ + -d $srv $dports -j $target + fi + done + done + else + if [ -n "$loglevel" -a -z "$natrule" ]; then + log_rule $loglevel $chain $logtarget \ + `fix_bang $proto $sports $multiport $state $cli $dports` + fi + + run_iptables2 -A $chain $proto $multiport $state $cli $sports \ + $dports -j $target fi - - run_iptables2 -A $chain $proto $multiport $state $cli $sports \ - $serv $dports -j $target fi fi else @@ -2218,11 +2284,11 @@ process_rule() # $1 = target fatal_error "Empty source zone or qualifier: rule \"$rule\"" fi - if [ "$clientzone" = "${clientzone%\!*}" ]; then + if [ "$clientzone" = "${clientzone%!*}" ]; then excludezones= else - excludezones="${clientzone#*\!}" - clientzone="${clientzone%\!*}" + excludezones="${clientzone#*!}" + clientzone="${clientzone%!*}" [ "$logtarget" = DNAT ] || [ "$logtarget" = REDIRECT ] ||\ fatal_error "Exclude list only allowed with DNAT or REDIRECT" @@ -2293,42 +2359,83 @@ process_rule() # $1 = target # Generate Netfilter rule(s) - if [ -n "$MULTIPORT" -a \ - "$ports" = "${ports%:*}" -a \ - "$cports" = "${cports%:*}" -a \ - `list_count $ports` -le 15 -a \ - `list_count $cports` -le 15 ] - then - # - # MULTIPORT is enabled, there are no port ranges in the rule and less than - # 16 ports are listed - use multiport match. - # - multioption="-m multiport" - for client in `separate_list ${clients:=-}`; do - for server in `separate_list ${servers:=-}`; do - # - # add_a_rule() modifies these so we must set their values each time - # - port=${ports:=-} - cport=${cports:=-} - add_a_rule - done - done - else - # - # MULTIPORT is disabled or the rule isn't compatible with multiport match - # - multioption= - for client in `separate_list ${clients:=-}`; do - for server in `separate_list ${servers:=-}`; do - for port in `separate_list ${ports:=-}`; do - for cport in `separate_list ${cports:=-}`; do + case $logtarget in + DNAT*) + if [ -n "$MULTIPORT" -a \ + "$ports" = "${ports%:*}" -a \ + "$cports" = "${cports%:*}" -a \ + `list_count $ports` -le 15 -a \ + `list_count $cports` -le 15 ] + then + # + # MULTIPORT is enabled, there are no port ranges in the rule and less than + # 16 ports are listed - use multiport match. + # + multioption="-m multiport" + for client in `separate_list ${clients:=-}`; do + # + # add_a_rule() modifies these so we must set their values each time + # + server=${servers:=-} + port=${ports:=-} + cport=${cports:=-} + add_a_rule + done + else + # + # MULTIPORT is disabled or the rule isn't compatible with multiport match + # + multioption= + for client in `separate_list ${clients:=-}`; do + for port in `separate_list ${ports:=-}`; do + for cport in `separate_list ${cports:=-}`; do + server=${servers:=-} + add_a_rule + done + done + done + fi + ;; + *) + + if [ -n "$MULTIPORT" -a \ + "$ports" = "${ports%:*}" -a \ + "$cports" = "${cports%:*}" -a \ + `list_count $ports` -le 15 -a \ + `list_count $cports` -le 15 ] + then + # + # MULTIPORT is enabled, there are no port ranges in the rule and less than + # 16 ports are listed - use multiport match. + # + multioption="-m multiport" + for client in `separate_list ${clients:=-}`; do + for server in `separate_list ${servers:=-}`; do + # + # add_a_rule() modifies these so we must set their values each time + # + port=${ports:=-} + cport=${cports:=-} add_a_rule done done - done - done - fi + else + # + # MULTIPORT is disabled or the rule isn't compatible with multiport match + # + multioption= + for client in `separate_list ${clients:=-}`; do + for server in `separate_list ${servers:=-}`; do + for port in `separate_list ${ports:=-}`; do + for cport in `separate_list ${cports:=-}`; do + add_a_rule + done + done + done + done + fi + ;; + esac # # Report Result # @@ -2360,7 +2467,7 @@ process_rules() # $1 = name of rules file while read xtarget xclients xservers xprotocol xports xcports xaddress; do case "${xtarget%:*}" in - ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|REDIRECT-|LOG|CONTINUE) + ACCEPT|DROP|REJECT|DNAT|DNAT-|REDIRECT|REDIRECT-|LOG|CONTINUE) expandv xclients xservers xprotocol xports xcports xaddress if [ "x$xclients" = xall ]; then @@ -2382,7 +2489,7 @@ process_rules() # $1 = name of rules file ;; *) rule="`echo $xtarget $xclients $xservers $xprotocol $xports $xcports $xaddress`" - fatal_error "Invalid Target in rule \"$rule\"" + fatal_error "Invalid Action in rule \"$rule\"" ;; esac @@ -2582,24 +2689,19 @@ loadmodule() # $1 = module name, $2 - * arguments { local modulename=$1 local modulefile + local suffix if [ -z "`lsmod | grep $modulename`" ]; then shift - modulefile=$MODULESDIR/${modulename}.o + + for suffix in o gz ko ; do + modulefile=$MODULESDIR/${modulename}.${suffix} - if [ -f $modulefile ]; then - insmod $modulefile $* - return - fi - # - # If the modules directory contains compressed modules then we'll - # assume that insmod can load them - # - modulefile=${modulefile}.gz - - if [ -f $modulefile ]; then - insmod $modulefile $* - fi + if [ -f $modulefile ]; then + insmod $modulefile $* + return + fi + done fi } @@ -2900,8 +3002,16 @@ setup_masq() esac if [ -n "$address" -a -n "$ADD_SNAT_ALIASES" ]; then - list_search $address $aliases_to_add || \ - aliases_to_add="$aliases_to_add $address $fullinterface" + for addr in `ip_range $address` ; do + if ! list_search $addr $aliases_to_add; then + aliases_to_add="$aliases_to_add $addr $fullinterface" + case $fullinterface in + *:*) + fullinterface=${fullinterface%:*}:$((${fullinterface#*:} + 1 )) + ;; + esac + fi + done fi destination=$destnet @@ -3118,7 +3228,7 @@ verify_os_version() { osversion=`uname -r` case $osversion in - 2.4.*|2.5.*) + 2.4.*|2.5.*|2.6.*) ;; *) startup_error "Shorewall version $version does not work with kernel version $osversion" @@ -3134,35 +3244,30 @@ verify_os_version() { # add_ip_aliases() { - local external - local interface - local primary + local addresses external interface inet cidr rest val - do_one() + address_details() { # # Folks feel uneasy if they don't see all of the same # decoration on these IP addresses that they see when their # distro's net config tool adds them. In an attempt to reduce # the anxiety level, we have the following code which sets - # the VLSM and BRD from the primary address + # the VLSM and BRD from an existing address in the same subnet # - # Get all of the lines that contain inet addresses with broadcast + # Get all of the lines that contain inet addresses # - val=`ip addr show $interface | grep 'inet.*brd '` 2> /dev/null - - if [ -n "$val" ] ; then - # - # Hack off the leading 'inet ' (actually cut off the - # "/" as well but add it back in). - # - val="/${val#*/}" - # - # Now get the VLSM, "brd" and the broadcast address - # - val=${val%% scope*} - fi + ip addr show $interface 2> /dev/null | grep 'inet' | while read inet cidr rest ; do + if in_subnet $external $cidr; then + echo "/${cidr#*/} brd `broadcastaddress $cidr`" + break + fi + done + } + do_one() + { + val=`address_details` run_ip addr add ${external}${val} dev $interface $label echo "$external $interface" >> ${STATEDIR}/nat [ -n "$label" ] && label="with $label" @@ -3182,9 +3287,9 @@ add_ip_aliases() label="label $interface:$label" fi - primary=`find_interface_address $interface` shift;shift - [ "x${primary}" = "x${external}" ] || do_one + + list_search $external `find_interface_addresses $interface` || do_one done } @@ -3207,10 +3312,46 @@ load_kernel_modules() { # Verify that the 'ip' program is installed verify_ip() { - qt which ip ||\ + qt ip link ls ||\ startup_error "Shorewall $version requires the iproute package ('ip' utility)" } +# +# Determine which optional facilities are supported by iptables/netfilter +# +determine_capabilities() { + qt iptables -t nat -L -n && NAT_ENABLED=Yes || NAT_ENABLED= + qt iptables -t mangle -L -n && MANGLE_ENABLED=Yes || MANGLE_ENABLED= + + CONNTRACK_MATCH= + MULTIPORT= + + if qt iptables -N fooX1234 ; then + qt iptables -A fooX1234 -m conntrack --ctorigdst 192.168.1.1 -j ACCEPT && CONNTRACK_MATCH=Yes + qt iptables -A fooX1234 -p tcp -m multiport --dports 21,22 -j ACCEPT && MULTIPORT=Yes + + qt iptables -F fooX1234 + qt iptables -X fooX1234 + fi +} + +report_capability() # $1 = Capability Name, $2 Capability Setting (if any) +{ + local setting= + + [ "x$1" = "xYes" ] && { setting="Available"; shift; } || setting="Not available" + + echo " " $@: $setting +} + +report_capabilities() { + echo "Shorewall has detected the following iptables/netfilter capabilities:" + report_capability $NAT_ENABLED "NAT" + report_capability $MANGLE_ENABLED "Packet Mangling" + report_capability $MULTIPORT "Multi-port Match" + report_capability $CONNTRACK_MATCH "Connection Tracking Match" +} + # # Perform Initialization # - Delete all old rules @@ -3221,6 +3362,8 @@ verify_ip() { # initialize_netfilter () { + report_capabilities + echo "Determining Zones..." determine_zones @@ -3307,7 +3450,16 @@ initialize_netfilter () { if [ -z "$NEWNOTSYN" ]; then createchain newnotsyn no + + for interface in `find_interfaces_by_option newnotsyn`; do + run_iptables -A newnotsyn -i $interface -p tcp --tcp-flags ACK ACK -j ACCEPT + run_iptables -A newnotsyn -i $interface -p tcp --tcp-flags RST RST -j ACCEPT + run_iptables -A newnotsyn -i $interface -p tcp --tcp-flags FIN FIN -j ACCEPT + run_iptables -A newnotsyn -i $interface -j RETURN + done + run_user_exit newnotsyn + if [ -n "$LOGNEWNOTSYN" ]; then log_rule $LOGNEWNOTSYN newnotsyn DROP fi @@ -3334,7 +3486,7 @@ initialize_netfilter () { done < /var/lib/shorewall/save fi - echo "Creating input Chains..." + echo "Creating Interface Chains..." for interface in $all_interfaces; do createchain `forward_chain $interface` no @@ -3369,6 +3521,7 @@ build_common_chain() { if [ -n "$NEWNOTSYN" ]; then run_iptables -A common -p tcp --tcp-flags ACK ACK -j ACCEPT run_iptables -A common -p tcp --tcp-flags RST RST -j ACCEPT + run_iptables -A common -p tcp --tcp-flags FIN FIN -j ACCEPT fi # # BROADCASTS @@ -3462,13 +3615,17 @@ add_common_rules() { # # DHCP # - echo "Adding rules for DHCP" + interfaces=`find_interfaces_by_option dhcp` - for interface in `find_interfaces_by_option dhcp`; do - run_iptables -A `input_chain $interface` -p udp --dport 67:68 -j ACCEPT - run_iptables -A OUTPUT -o $interface -p udp --dport 67:68 -j ACCEPT - done + if [ -n "$interfaces" ]; then + echo "Adding rules for DHCP" + + for interface in $interfaces; do + run_iptables -A `input_chain $interface` -p udp --dport 67:68 -j ACCEPT + run_iptables -A OUTPUT -o $interface -p udp --dport 67:68 -j ACCEPT + done + fi # # RFC 1918 # @@ -3487,11 +3644,12 @@ add_common_rules() { run_iptables -A logdrop -j DROP - if [ -n "$MANGLE_ENABLED" ]; then + if [ -n "$MANGLE_ENABLED" -a -z "$CONNTRACK_MATCH" ]; then # - # Mangling is enabled -- create a chain in the mangle table to - # filter RFC1918 destination addresses. This must be done in the - # mangle table before we apply any DNAT rules in the nat table + # Mangling is enabled but conntrack match isn't available -- + # create a chain in the mangle table to filter RFC1918 destination + # addresses. This must be done in the mangle table before we apply + # any DNAT rules in the nat table # # Also add a chain to log and drop any RFC1918 packets that we find # @@ -3511,11 +3669,17 @@ add_common_rules() { esac run_iptables2 -A rfc1918 -s $subnet -j $target - # - # If packet mangling is enabled, trap packets with an - # RFC1918 destination - # - if [ -n "$MANGLE_ENABLED" ]; then + + if [ -n "$CONNTRACK_MATCH" ]; then + # + # We have connection tracking match -- match on the original destination + # + run_iptables2 -A rfc1918 -m conntrack --ctorigdst $subnet -j $target + elif [ -n "$MANGLE_ENABLED" ]; then + # + # No connection tracking match but we have mangling -- add a rule to + # the mangle table + # run_iptables2 -t mangle -A man1918 -d $subnet -j $target fi done < $TMP_DIR/rfc1918 @@ -3525,7 +3689,7 @@ add_common_rules() { run_iptables -A $chain -m state --state NEW -j rfc1918 done - [ -n "$MANGLE_ENABLED" ] && \ + [ -n "$MANGLE_ENABLED" -a -z "$CONNTRACK_MATCH" ] && \ run_iptables -t mangle -A PREROUTING -m state --state NEW -i $interface -j man1918 done @@ -4366,6 +4530,7 @@ added_param_value_no() # $1 = Parameter Name, $2 = Parameter value # Initialize this program # do_initialize() { + # Run all utility programs using the C locale # # Thanks to Vincent Planchenault for this tip # @@ -4388,8 +4553,6 @@ do_initialize() { LOGRATE= LOGBURST= LOGPARMS= - NAT_ENABLED= - MANGLE_ENABLED= ADD_IP_ALIASES= ADD_SNAT_ALIASES= TC_ENABLED= @@ -4399,7 +4562,6 @@ do_initialize() { CLAMPMSS= ROUTE_FILTER= NAT_BEFORE_RULES= - MULTIPORT= DETECT_DNAT_IPADDRS= MUTEX_TIMEOUT= NEWNOTSYN= @@ -4433,6 +4595,7 @@ do_initialize() { FUNCTIONS=$SHARED_DIR/functions if [ -f $FUNCTIONS ]; then + echo "Loading $FUNCTIONS..." . $FUNCTIONS else startup_error "$FUNCTIONS does not exist!" @@ -4463,8 +4626,6 @@ do_initialize() { ALLOWRELATED="`added_param_value_yes ALLOWRELATED $ALLOWRELATED`" [ -n "$ALLOWRELATED" ] || \ startup_error "ALLOWRELATED=No is not supported" - NAT_ENABLED="`added_param_value_yes NAT_ENABLED $NAT_ENABLED`" - MANGLE_ENABLED="`added_param_value_yes MANGLE_ENABLED $MANGLE_ENABLED`" ADD_IP_ALIASES="`added_param_value_yes ADD_IP_ALIASES $ADD_IP_ALIASES`" TC_ENABLED="`added_param_value_yes TC_ENABLED $TC_ENABLED`" @@ -4496,7 +4657,6 @@ do_initialize() { ADD_SNAT_ALIASES=`added_param_value_no ADD_SNAT_ALIASES $ADD_SNAT_ALIASES` ROUTE_FILTER=`added_param_value_no ROUTE_FILTER $ROUTE_FILTER` NAT_BEFORE_RULES=`added_param_value_yes NAT_BEFORE_RULES $NAT_BEFORE_RULES` - MULTIPORT=`added_param_value_no MULTIPORT $MULTIPORT` DETECT_DNAT_IPADDRS=`added_param_value_no DETECT_DNAT_IPADDRS $DETECT_DNAT_IPADDRS` FORWARDPING=`added_param_value_no FORWARDPING $FORWARDPING` [ -n "$FORWARDPING" ] && \ @@ -4567,6 +4727,19 @@ do_initialize() { # strip_file interfaces strip_file hosts + # + # Determine the capabilities of the installed iptables/netfilter + # + determine_capabilities + # + # Check out the user's shell + # + [ -n "$SHOREWALL_SHELL" ] || SHOREWALL_SHELL=/bin/sh + + temp=`decodeaddr 192.168.1.1` + if [ `encodeaddr $temp` != 192.168.1.1 ]; then + startup_error "Shell $SHOREWALL_SHELL is broken and may not be used with Shorewall" + fi } # @@ -4719,6 +4892,15 @@ case "$command" in my_mutex_off ;; + call) + # + # Undocumented way to call functions in /usr/share/shorewall/firewall directly + # + shift; + do_initialize + EMPTY= + $@ + ;; *) usage ;; diff --git a/Lrp/usr/share/shorewall/functions b/Lrp/usr/share/shorewall/functions index 746a86657..3fc8bc5d0 100644 --- a/Lrp/usr/share/shorewall/functions +++ b/Lrp/usr/share/shorewall/functions @@ -83,29 +83,23 @@ find_display() # $1 = zone, $2 = name of the zone file [ "x$1" = "x$z" ] && echo $display done } - +# +# This function assumes that the TMP_DIR variable is set and that +# its value named an existing directory. +# determine_zones() { local zonefile=`find_file zones` multi_display=Multi-zone - - if [ -f $zonefile ]; then - zones=`find_zones $zonefile` - zones=`echo $zones` # Remove extra trash - - for zone in $zones; do - dsply=`find_display $zone $zonefile` - eval ${zone}_display=\$dsply - done - else - zones="net local dmz gw" - net_display=Net - local_display=Local - dmz_display=DMZ - gw_display=Gateway - fi - + strip_file zones $zonefile + zones=`find_zones $TMP_DIR/zones` + zones=`echo $zones` # Remove extra trash + + for zone in $zones; do + dsply=`find_display $zone $TMP_DIR/zones` + eval ${zone}_display=\$dsply + done } # @@ -225,3 +219,164 @@ strip_file() # $1 = Base Name of the file, $2 = Full Name of File (optional) > $TMP_DIR/$1 fi } + +# +# Note: The following set of IP address manipulation functions have anomalous +# behavior when the shell only supports 32-bit signed arithmatic and +# the IP address is 128.0.0.0 or 128.0.0.1. +# +# +# So that emacs doesn't get lost, we use $LEFTSHIFT rather than << +# +LEFTSHIFT='<<' + +# +# Convert an IP address in dot quad format to an integer +# +decodeaddr() { + local x + local temp=0 + local ifs=$IFS + + IFS=. + + for x in $1; do + temp=$(( $(( $temp $LEFTSHIFT 8 )) | $x )) + done + + echo $temp + + IFS=$ifs +} + +# +# convert an integer to dot quad format +# +encodeaddr() { + addr=$1 + local x + local y=$(($addr & 255)) + + for x in 1 2 3 ; do + addr=$(($addr >> 8)) + y=$(($addr & 255)).$y + done + + echo $y +} + +# +# Enumerate the members of an IP range -- When using a shell supporting only +# 32-bit signed arithmetic, the range cannot span 128.0.0.0. +# +ip_range() { + local first last l x y z vlsm + + case $1 in + [0-9]*.*.*.*-*.*.*.*) + ;; + *) + echo $1 + return + ;; + esac + + first=`decodeaddr ${1%-*}` + last=`decodeaddr ${1#*-}` + + if [ $first -gt $last ]; then + fatal_error "Invalid IP address range: $1" + fi + + l=$(( $last + 1 )) + + while [ $first -le $last ]; do + vlsm= + x=31 + y=2 + z=1 + + while [ $(( $first % $y )) -eq 0 -a $(( $first + $y )) -le $l ]; do + vlsm=/$x + x=$(( $x - 1 )) + z=$y + y=$(( $y * 2 )) + done + + echo `encodeaddr $first`$vlsm + first=$(($first + $z)) + done +} + +# +# Netmask from CIDR +# +ip_netmask() { + local vlsm=${1#*/} + + [ $vlsm -eq 0 ] && echo 0 || echo $(( -1 $LEFTSHIFT $(( 32 - $vlsm )) )) +} + +# +# Network address from CIDR +# +ip_network() { + local decodedaddr=`decodeaddr ${1%/*}` + local netmask=`ip_netmask $1` + + echo `encodeaddr $(($decodedaddr & $netmask))` +} + +# +# The following hack is supplied to compensate for the fact that many of +# the popular light-weight Bourne shell derivatives don't support XOR ("^"). +# +# Note: 2147483647 = 0x7fffffff + +ip_broadcast() { + local x=$(( ${1#*/} - 1 )) + + [ $x -eq -1 ] && echo -1 || echo $(( 2147483647 >> $x )) +} + +# +# Calculate broadcast address from CIDR +# +broadcastaddress() { + local decodedaddr=`decodeaddr ${1%/*}` + local netmask=`ip_netmask $1` + local broadcast=`ip_broadcast $1` + + echo `encodeaddr $(( $(($decodedaddr & $netmask)) | $broadcast ))` +} + +# +# Test for subnet membership +# +in_subnet() # $1 = IP address, $2 = CIDR network +{ + local netmask=`ip_netmask $2` + + test $(( `decodeaddr $1` & $netmask)) -eq $(( `decodeaddr ${2%/*}` & $netmask )) +} + +# +# Netmask to VLSM +# +ip_vlsm() { + local mask=`decodeaddr $1` + local vlsm=0 + local x=$(( 128 $LEFTSHIFT 24 )) + + while [ $(( $x & $mask )) -ne 0 ]; do + [ $mask -eq $x ] && mask=0 || mask=$(( $mask $LEFTSHIFT 1 )) # Don't Ask... + vlsm=$(($vlsm + 1)) + done + + if [ $(( $mask & 2147483647)) -ne 0 ]; then + echo "Invalid net mask: $1" >&2 + else + echo $vlsm + fi +} + diff --git a/Lrp/usr/share/shorewall/version b/Lrp/usr/share/shorewall/version index e516bb9d9..c514bd85c 100644 --- a/Lrp/usr/share/shorewall/version +++ b/Lrp/usr/share/shorewall/version @@ -1 +1 @@ -1.4.5 +1.4.6 diff --git a/Lrp/var/lib/lrpkg/shorwall.version b/Lrp/var/lib/lrpkg/shorwall.version index e516bb9d9..c514bd85c 100644 --- a/Lrp/var/lib/lrpkg/shorwall.version +++ b/Lrp/var/lib/lrpkg/shorwall.version @@ -1 +1 @@ -1.4.5 +1.4.6 diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index 6c9afeffb..aebaf9266 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,15 +1,53 @@ -Changes since 1.4.4b +Changes since 1.4.5 -1) The command "shorewall debug try " now correctly traces - the attempt. +1) Worked around RH7.3 "service" anomaly. -2) The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now - contain a list of addresses. If the list begins with "!' then the - rule will take effect only if the original destination address in - the connection request does not match any of the addresses listed. +2) Implemented 'newnotsyn' interface option. -3) Enhanced processing of the zones file to allow the INCLUDE - directive. - -4) Fix processing of the routestopped file's second column. +3) Document range in masq ADDRESS column and suppress ADD_SNAT_ALIASES + behavior in that case. +4) Enable ADD_SNAT_ALIASES=Yes for SNAT ranges. + +5) Allow Shorewall to add aliases to other than the first subnet on an + interface. + +6) Add support for load-balancing. + +7) Toned down the disclaimer for the 'check' command. + +8) Implemented support for the Connection Tracking Match extension in + iptables 1.2.8/Kernel 2.4.21. + +9) Removed the NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration + parameters and replaced them with code that detects these + capabilities. + +10) Added the SHOREWALL_SHELL configuraiton parameter. + +11) Fixed capability reporting (thanks to Simon Matter). + +12) Correct the implementation of destination IP list in DNAT[-] rules. + +13) Check for shells whose arithmetic support is broken. + +14) Moved IP Address manipulation functions to + /usr/share/shorewall/functions. + +15. Added ipcalc command. + +16. Fixed handling of destination DNS names containing a "-" + +17. Make ip_range() smarter. + +18. Added /sbin/shorewall iprange command. + +19. Fixed handling of excluded zone processing in DNAT and REDIRECT + rules (re-added the protocol to the rule). Fixed parsing of exclude + zones. + +20. Display policy chain along with policy in 'check' command. + +21. Support Linux 2.6 compressed modules. + +22. Don't display DHCP message when there are no DHCP interface. diff --git a/STABLE/documentation/6to4.htm b/STABLE/documentation/6to4.htm index 13c232288..c7410c168 100755 --- a/STABLE/documentation/6to4.htm +++ b/STABLE/documentation/6to4.htm @@ -1,142 +1,143 @@ - + 6to4 Tunnels - + - + - + - - - + + - - - + + + +
+ id="AutoNumber1" bgcolor="#3366ff" height="90"> +

6to4 Tunnels

-
- +

The 6to4 tunnel documentation is provided by Eric de Thouars.
-

- -

Warning: The 6to4 tunnel feature of Shorewall -only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 security -measures.

- -

6to4 tunneling with Shorewall can be used to connect your IPv6 network -to another IPv6 network over an IPv4 infrastructure

- + + +

Warning: The 6to4 tunnel feature of Shorewall + only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 +security measures.

+ +

6to4 tunneling with Shorewall can be used to connect your IPv6 network + to another IPv6 network over an IPv4 infrastructure

+

More information on Linux and IPv6 can be found in the Linux IPv6 HOWTO. Details -on how to setup a 6to4 tunnels are described in the section Setup - of 6to4 tunnels.

- + href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO">Linux IPv6 HOWTO. +Details on how to setup a 6to4 tunnels are described in the section Setup + of 6to4 tunnels.

+

Connecting two IPv6 Networks

- +

Suppose that we have the following situation:

- +

-

- -

We want systems in the 2002:100:333::/64 subnetwork to be -able to communicate with the systems in the 2002:488:999::/64 network. This -is accomplished through use of the /etc/shorewall/tunnels file and the "ip" -utility for network interface and routing configuration.

- -

Unlike GRE and IPIP tunneling, the /etc/shorewall/policy, -/etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There -is no need to declare a zone to represent the remote IPv6 network. This remote -network is not visible on IPv4 interfaces and to iptables. All that is visible -on the IPv4 level is an IPv4 stream which contains IPv6 traffic. Separate -IPv6 interfaces and ip6tables rules need to be defined to handle this traffic. -

- +

+ +

We want systems in the 2002:100:333::/64 subnetwork to be + able to communicate with the systems in the 2002:488:999::/64 network. This + is accomplished through use of the /etc/shorewall/tunnels file and the "ip" + utility for network interface and routing configuration.

+ +

Unlike GRE and IPIP tunneling, the /etc/shorewall/policy, + /etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There + is no need to declare a zone to represent the remote IPv6 network. This +remote network is not visible on IPv4 interfaces and to iptables. All that +is visible on the IPv4 level is an IPv4 stream which contains IPv6 traffic. + Separate IPv6 interfaces and ip6tables rules need to be defined to handle +this traffic.

+

In /etc/shorewall/tunnels on system A, we need the following:

- -
+ +
- + + + + + + + - - - - - - - - - - - - - + + + + + + +
TYPEZONEGATEWAYGATEWAY ZONE
TYPEZONEGATEWAYGATEWAY ZONE
6to4net134.28.54.2 
6to4net134.28.54.2 
-
- -

This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6 +

+ +

This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6 encapsulation protocol (41) will be accepted to/from the remote gateway.

- +

Use the following commands to setup system A:

- -
+ +

>ip tunnel add tun6to4 mode sit ttl 254 remote 134.28.54.2
- >ip link set dev tun6to4 up
- >ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4
- >ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2

-
- + >ip link set dev tun6to4 up
+ >ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4
+ >ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2

+
+

Similarly, in /etc/shorewall/tunnels on system B we have:

- -
+ +
- + + + + + + + - - - - - - - - - - - - - + + + + + + +
TYPEZONEGATEWAYGATEWAY ZONE
TYPEZONEGATEWAYGATEWAY ZONE
6to4net206.191.148.9 
6to4net206.191.148.9 
-
- +
+

And use the following commands to setup system B:

- -
+ +

>ip tunnel add tun6to4 mode sit ttl 254 remote 206.191.148.9
- >ip link set dev tun6to4 up
- >ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4
- >ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1

-
- -

On both systems, restart Shorewall and issue the configuration commands -as listed above. The systems in both IPv6 subnetworks can now talk to each -other using IPv6.

- -

Updated 5/18/2003 - Tom Eastep + >ip link set dev tun6to4 up
+ >ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4
+ >ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1

+
+ +

On both systems, restart Shorewall and issue the configuration commands + as listed above. The systems in both IPv6 subnetworks can now talk to each + other using IPv6.

+ +

Updated 5/18/2003 - Tom Eastep

- +

Copyright © 2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.

-
+
+


diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index 83ef99edd..737efb0d7 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -1,297 +1,323 @@ - + + - + + - + + Shorewall 1.4 Documentation - + + + - + + - + + - + - - - + + - - - -
+ bgcolor="#3366ff" height="90"> +
- +

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

- -

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.
    • -
  • ecn -- a parameter file installed - in /etc/shorewall and used to selectively disable Explicit Congestion - Notification (ECN - RFC 3168).
    -
    • -
  • 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.
    -
    • -
  • + + +

    This documentation is intended primarily for reference. + 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.
      • +
    • ecn -- a parameter + file installed in /etc/shorewall and used to selectively disable + Explicit Congestion Notification (ECN - RFC 3168).
      +
      • +
    • 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.
      +
      • +
    • 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.
      -
      • -
    • 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.
      • -
    • 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 .
      • -
    • static NAT .
      • +
    • proxyarp -- a parameter file in - /etc/shorewall used to define Proxy Arp - .
      • -
    • Proxy + Arp .
      • +
    • rfc1918 -- a parameter file in /etc/shorewall used to define the treatment of packets under - the norfc1918 interface option.
      • -
    • 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.
      • - + (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=blacklist,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 blacklist,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 (4 characters or less if you are running Shorewall -1.4.4 or later) 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 (4 characters or less if you are running Shorewall + 1.4.4 or later) 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
    netNetInternet
    locLocalLocal networks
    dmzDMZDemilitarized -zone
    + ZONE + DISPLAY + COMMENTS
    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+). -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": - +
    • 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": +
        -
      • 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).
        • +
      • 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:
      -
      - routeback (Added in version 1.4.2) - This option causes - Shorewall to set up handling for routing packets that arrive on this -interface back out the same interface. If this option is specified, the -ZONE column may not contain "-".
      +
      • +
    • OPTIONS + - a comma-separated list of options. Possible options + include:
      +
      + newnotsyn (Added in version 1.4.6) - This +option overrides NEWNOTSYN=No for packets arriving +on this interface. In other words, packets coming in on this interface +are processed as if NEWNOTSYN=Yes had been specified in /etc/shorewall/shorewall.conf.
      +
      + routeback       (Added in version 1.4.2) - This option causes Shorewall + to set up handling for routing packets that arrive on this interface + back out the same interface. If this option is specified, the ZONE +column may not contain "-".
      +

      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. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH; these @@ -299,1910 +325,2151 @@ 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).

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

      - +

      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.

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

      - +

      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 available - for download. I am currently - running this patch applied to kernel - 2.4.16.

      + 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, 0000080A...) + 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 <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 MAC Verification. May only be specified - for ethernet interfaces.

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

      + +
    - +

    My recommendations concerning options:
    -

    - +

    +
      -
    • External Interface -- tcpflags,blacklist,norfc1918,routefilter
      • -
    • 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 and proxyarp - when needed.
      -
      • - +
    • External Interface -- + tcpflags,blacklist,norfc1918,routefilter
      • +
    • 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 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 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 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,norfc1918,blacklist
    loceth1detect
    -
    + ZONE + INTERFACE + BROADCAST + OPTIONS
    neteth0detectdhcp,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

    - -
    + 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: The only times that you need entries in /etc/shorewall/hosts are:
    -

    - +

    +
      -
    1. You have more than one zone connecting through a single - interface; or
      2. -
    2. You have a zone that has multiple subnetworks that connect - through a single interface and you want the Shorewall box to route traffic - between those subnetworks.
      -
      3. - +
    3. You have more than one zone connecting through + a single interface; or
      4. +
    4. You have a zone that has multiple subnetworks + that connect through a single interface and you want the Shorewall + box to route traffic between those subnetworks.
      +
      5. +
    - IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN DON'T TOUCH - THIS FILE!! + IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN + DON'T TOUCH THIS FILE!!

    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 a comma-separated list either:
      • +
    - -
    + +
    +
      -
    1. An IP -address (example - eth1:192.168.1.3)
      2. -
    2. A subnet - in CIDR notation (example - - eth2:192.168.2.0/24)
      3. - + +
    3. An IP address (example - eth1:192.168.1.3)
      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.

    -
    - + + +

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

    + +

    Warning: If you are running a +version of Shorewall earlier than 1.4.6, only a single host/subnet address +may be specified in an entry in /etc/shorewall/hosts.
    +

    +
    +
      -
    • OPTIONS - A -comma-separated list of option
      • - +
    • OPTIONS + - A comma-separated list of option
      • +
    - -
    + +
    +

    routeback (Added in version 1.4.2) - This option causes Shorewall - to set up handling for routing packets sent by this host group back back - to the same group.
    -
    - 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.
    -

    -
    - + to set up handling for routing packets sent by this host group back + back to the same group.
    +
    + 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.
    +

    +
    +

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

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

    +

    Example 1:

    - +

    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/
      • - +
    • 192.168.1.0/25 +
      • +
    • 192.168.1.128/
      • +
    - +

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

    - -
    + +
    + - + - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + - - + + +
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918
    -eth1192.168.1.127,192.168.1.255
    -
    -
    + ZONE + INTERFACE + BROADCAST + OPTIONS
    neteth0detectdhcp,norfc1918
    -eth1192.168.1.127,192.168.1.255
    +
    +
    -
    - +
    +

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

    - + 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/25
    -
    + ZONE + HOST(S) + OPTIONS
    loc1eth1:192.168.1.0/25
    +
    loc2eth1:192.168.1.128/25
    +
    -
    - + +

    Example 2:

    - +

    Your local interface is eth1 and you have two groups of local hosts that - you want to consider as one zone and you want Shorewall to route between - them:

    - + you want to consider as one zone and you want Shorewall to route + between them:

    +
      -
    • 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,norfc1918
    loc
    -     		eth1192.168.1.127,192.168.1.255
    -
    -
    + ZONE + INTERFACE + BROADCAST + OPTIONS
    neteth0detectdhcp,norfc1918
    loc
    +     		eth1192.168.1.127,192.168.1.255
    +
    +
    -
    - +
    +

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

    - +
    - + + - + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + - + + +
    ZONE HOST(S) OPTIONS
    loceth1:192.168.1.0/25
    -
    loceth1:192.168.1.128/25
    -
    + ZONE + HOST(S) + OPTIONS
    loceth1:192.168.1.0/25
    +
    loceth1:192.168.1.128/25
    +
    -
    - + + If you are running Shorewall +1.4.6 or later, your hosts file may look like:
    + +
    + + + + + + + + + + + + + + + + + + +
    + ZONE + HOST(S) + OPTIONS
    loceth1:192.168.1.0/25,192.168.1.128/25
    +
    +
    +
    +

    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.

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

    - + of all of those zones. This is done through use + of the special CONTINUE policy described + below.

    +

    /etc/shorewall/policy - Configuration.

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

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

    - + 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.
      • -
    • NONE - (Added in version 1.4.1) - Shorewall should - not set up any infrastructure for handling traffic from the SOURCE zone - to the DEST zone. When this policy is specified, the LOG LEVEL and - BURST:LIMIT columns must be left blank.
      -
      • - +
    • 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.
      • +
    • NONE - (Added in version 1.4.1) - Shorewall + should not set up any infrastructure for handling traffic from +the SOURCE zone to the DEST zone. When this policy is specified, +the LOG LEVEL and BURST:LIMIT columns +must be left blank.
      +
      • +
    - +

    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.

    - + 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. SOURCE - The name of a client + zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall + zone or "all").
      3. -
    3. 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.
      4. +
    4. 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.
      5. -
    5. POLICY - The default policy for connection - requests from the SOURCE zone to the DESTINATION zone.
      6. +
    6. POLICY - The default policy + for connection requests from the SOURCE zone to the DESTINATION + zone.
      7. -
    7. 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.
      8. +
    8. 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.
      9. -
    9. 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.
      10. - +
    10. 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.
      11. +
    - +

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

    - + zones.

    +

    The policy file installed by default is as follows:

    - +
    - + + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + +
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    -
    -
    netallDROPinfo
    -
    allallREJECTinfo
    -
    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.
      • - +
    • 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.

    - + /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
    -
    SOURCEDESTPOLICYLOG + LEVELLIMIT:BURST
    locallACCEPT
    +
    +
    netallDROPinfo
    +
    loclocREJECTinfo
    +
    -
    - + +

    IntraZone Traffic

    - Shorewall allows a zone to be associated with more than one interface - or with multiple networks that interface through a single interface. -Beginning with Shorewall 1.4.1, Shorewall will ACCEPT all traffic from -a zone to itself provided that there is no explicit policy governing traffic -from that zone to itself (an explicit policy does not specify "all" in -either the SOURCE or DEST column) and that there are no rules concerning -connections from that zone to itself. If there is an explicit policy or -if there are one or more rules, then traffic within the zone is handled -just like traffic between zones is.
    - + Shorewall allows a zone to be associated with more +than one interface or with multiple networks that interface through +a single interface. Beginning with Shorewall 1.4.1, Shorewall will +ACCEPT all traffic from a zone to itself provided that there is no +explicit policy governing traffic from that zone to itself (an explicit +policy does not specify "all" in either the SOURCE or DEST column) and +that there are no rules concerning connections from that zone to itself. +If there is an explicit policy or if there are one or more rules, then +traffic within the zone is handled just like traffic between zones is.
    +

    Any time that you have multiple interfaces associated with a single zone, - you should ask yourself if you really want traffic routed between those - interfaces. Cases where you might not want that behavior are:
    -

    - + you should ask yourself if you really want traffic routed between + those interfaces. Cases where you might not want that behavior are:
    +

    +
      -
    1. Multiple 'net' interfaces to different ISPs. You don't -want to route traffic from one ISP to the other through your firewall.
      2. -
    2. Multiple VPN clients. You don't necessarily want them to - all be able to communicate between themselves using your gateway/router.
      -
      3. - +
    3. Multiple 'net' interfaces to different ISPs. +You don't want to route traffic from one ISP to the other through +your firewall.
      4. +
    4. Multiple VPN clients. You don't necessarily want + them to all be able to communicate between themselves using your +gateway/router.
      +
      5. +
    - +

    The CONTINUE - policy

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

    - + 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 + DISPLAY + COMMENTS
    samSamSam's + system at home
    netInternetThe +Internet
    locLocLocal + Network
    -
    - +
    +

    /etc/shorewall/interfaces:

    - -
    + +
    + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
    ZONE INTERFACE BROADCAST OPTIONS
    -eth0detectdhcp,norfc1918
    loceth1detect
    -
    + ZONE + INTERFACE + BROADCAST + OPTIONS
    -eth0detectdhcp,norfc1918
    loceth1detect
    +
    -
    - +
    +

    /etc/shorewall/hosts:

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

    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.

    - + and the + net zone and as described +above , that means that sam must be listed before +net in /etc/shorewall/zones.

    +

    /etc/shorewall/policy:

    - +
    - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + +
    SOURCE DEST POLICY LOG LEVEL
    locnetACCEPT
    -
    samallCONTINUE
    -
    netallDROPinfo
    allallREJECTinfo
    + 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).

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

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

    - -
    + 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-
    -
    ...
    -
    -
    -
    -
    -
    -
    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 net zone - with the exception of those in the 'sam' - zone should have their 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.

    - + with the exception of those in the +'sam' zone should have their +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.

    +

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

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

    - + 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 - +
    • ACTION + +
        -
      • ACCEPT, DROP, REJECT, - CONTINUE. 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"
        • -
      • DNAT- -- The above ACTION (DNAT) - generates two iptables rules: 1) and header-rewriting rule -in the Netfilter 'nat' table and; 2) an ACCEPT rule in the Netfilter - 'filter' table. DNAT- works like DNAT but only generates the -header-rewriting rule.
        -
        • -
      • REDIRECT -- Causes -the connection request to be redirected to a port on - the local (firewall) system.
        • -
      • REDIRECT- -- The above ACTION (REDIRECT) generates two - iptables rules: 1) and header-rewriting rule in the Netfilter - 'nat' table and; 2) an ACCEPT rule in the Netfilter 'filter' table. - REDIRECT- works like REDIRECT but only generates the header-rewriting - rule.
        -
        • -
      • LOG - Log the packet -- requires a syslog level - (see below).
        • +
      • ACCEPT, DROP, + REJECT, CONTINUE. 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"
        • +
      • DNAT- -- The above ACTION + (DNAT) generates two iptables rules: 1) and header-rewriting + rule in the Netfilter 'nat' table and; 2) an ACCEPT rule +in the Netfilter 'filter' table. DNAT- works like DNAT but only +generates the header-rewriting rule.
        +
        • +
      • REDIRECT +-- Causes the connection request to be redirected to + a port on the local (firewall) system.
        • +
      • REDIRECT- -- The above ACTION (REDIRECT) generates + two iptables rules: 1) and header-rewriting rule in the Netfilter + 'nat' table and; 2) an ACCEPT rule in the Netfilter 'filter' + table. REDIRECT- works like REDIRECT but only generates the header-rewriting + rule.
        +
        • +
      • LOG - Log the packet -- requires a syslog + level (see below).
        • - +
      - +

      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. Note: if the ACTION is LOG then you MUST specify a syslog level.
      -
      - 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: - +
      + 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).
        • +
      • 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 most 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.
        • + +
      • DEST +- Describes the destination host(s) to which the rule + applies. May take most of the forms described above for + SOURCE plus the following two additional forms: - -
      - Restrictions:
      - -
        -
      • MAC addresses may not be specified.
        • -
      • In DNAT rules, only an IP address may be given -- -DNS names are not permitted.
        • -
      • You may not specify both an IP address and an interface - name in the DEST column.
        -
        • - -
      -
      • -
    • PROTO - Protocol. - Must be a protocol name from /etc/protocols, a number or - "all". Specifies the protocol of the connection request.
      • -
    • 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 particular IP addresses (see Example 2 -below for another usage). Those IP addresses are specified in the - ORIGINAL DEST column as a comma-separated list.
      -
      - The IP address(es) 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.
      -
      -If this list begins with "!" then the rule will only apply if the original -destination address matches none of the addresses listed.
      -
      - 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.
      • - -
    +
      +
    • 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.
      • + + +
    + Restrictions:
    + + +
      +
    • MAC addresses may not be specified.
      • +
    • In DNAT rules, only IP addresses may be +given -- DNS names are not permitted.
      • +
    • You may not specify both an IP address +and an interface name in the DEST column.
      • + + +
    + Unlike in the SOURCE column, a range of IP addresses may be specified + in the DEST column as <first address>-<last address>. + When the ACTION is DNAT or DNAT-, connections will be assigned to +the addresses in the range in a round-robin fashion (load-balancing).
    +
    • +
  • PROTO + - Protocol. Must be a protocol name from /etc/protocols, + a number or "all". Specifies the protocol of the connection + request.
    • +
  • 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 particular IP addresses +(see Example 2 below for another usage). Those IP addresses are specified +in the ORIGINAL DEST column as a comma-separated list.
    +
    + The IP address(es) + 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.
    +
    + If this list begins with "!" then the rule will only apply if the + original destination address matches none of the addresses listed.
    +
    + 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 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
-
-
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.

- + 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
-
-
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
-
-
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 the ORIGINAL -DEST column blank in the first -rule. You cannot leave -it blank in the second -rule though because - then all ftp connections originating in the local - subnet 192.168.1.0/24 would be sent to 192.168.2.2 - regardless of the site that - the user was trying to - connect to. That is - clearly not what you - want 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 leave it blank in the + second rule though because + then all ftp connections originating in +the local subnet 192.168.1.0/24 would be +sent to 192.168.2.2 regardless of + the site that the user +was trying to connect + to. That is clearly + not what you want - .

- + .

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

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 with MAC address 02:00:08:E3:FA:55.

- +
- + - - - - - - - - - - - - - - - - - - - - - - -
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.
- -
- - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + - - + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		all
- 		dmz
- 		tcp
- 		25
-
-
-
ACTIONSOURCEDEST + PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
+
+
+
-
- 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.
-
- Example 7. Your firewall's external - interface has several IP addresses but you only want to accept SSH connections - on address 206.124.146.176.
- -
+
+ + Example 6. You wish to allow access + to the SMTP server in your DMZ from all zones.
+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		net
- 		fw:206.124.146.176
- 		tcp
- 		22
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		all
+ 		dmz
+ 		tcp
+ 		25
+
+
+
-
- Example 8 (For advanced users running Shorewall version 1.3.13 - or later). From the internet, you with to forward tcp port - 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 - in your DMZ. You also want to allow access from the internet directly - to tcp port 25 on 192.0.2.177.
- -
+
+ 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.
+
+ Example 7. Your firewall's + external interface has several IP addresses but you only want to accept + SSH connections on address 206.124.146.176.
+ +
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
DNAT-
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
- 		0
- 		192.0.2.178
-
DNAT-
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
- 		0
- 		192.0.2.179
-
ACCEPT
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		net
+ 		fw:206.124.146.176
+ 		tcp
+ 		22
+
+
+
-
- Using "DNAT-" rather than "DNAT" avoids two - extra copies of the third rule from being generated.
- + + Example 8 (For advanced users running Shorewall version + 1.3.13 or later). From the internet, you with to forward + tcp port 25 directed to 192.0.2.178 and 192.0.2.179 to host + 192.0.2.177 in your DMZ. You also want to allow access from + the internet directly to tcp port 25 on 192.0.2.177.
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
DNAT-
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+ 		0
+ 		192.0.2.178
+
DNAT-
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+ 		0
+ 		192.0.2.179
+
ACCEPT
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+
+
+
+
+ Using "DNAT-" rather than "DNAT" + avoids two extra copies of the third rule from being generated.
+
+ Example 9 (Shorewall version 1.4.6 or later). You have 9 http + servers behind a Shorewall firewall and you want connection requests to + be distributed among your servers. The servers are 192.168.1.101-192.168.1.109.
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
DNAT
+ 		net
+ 		loc:192.168.1.101-192.168.1.109
+ 		tcp
+ 		80
+
+
+
+
+

Look here for information on other services.

- +

/etc/shorewall/common

- +

Shorewall allows definition of rules that apply between - all zones. By default, these rules - are defined in the file - /etc/shorewall/common.def - but may be modified to - suit individual - requirements. Rather than modify /etc/shorewall/common.def, - you should copy that - file to - /etc/shorewall/common - and modify that file.

- + all zones. By default, these rules + are defined in the file + /etc/shorewall/common.def + but may be modified to + suit individual + requirements. Rather 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. Beginning with Shorewall -version 1.3.14, if you have set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf, you can cause Shorewall - to create an alias label of the form interfacename:digit - (e.g., eth0:0) by placing that label in this column. See example - 5 below. Alias labels created in this way allow the alias to be visible - to the ipconfig utility. THAT IS THE ONLY THING THAT THIS LABEL -IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.
    • -
  • 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. When - using Shorewall 1.3.13 or earlier, when an interface name is specified, - Shorewall will only masquerade traffic from the first subnetwork on -the named interface; if the interface interfaces to more that one subnetwork, -you will need to add additional entries to this file for each of those -other subnetworks. Beginning with Shorewall 1.3.14, shorewall will masquerade/SNAT -traffic from any host that is routed through the named interface.
    -
    - 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. -If you specify an address in this column, it must be an IP address -configured on the INTERFACE or you must have ADD_SNAT_ALIASES enabled -in /etc/shorewall/shorewall.conf.
    • - +
  • 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. Beginning with +Shorewall version 1.3.14, if you have set ADD_SNAT_ALIASES=Yes in + /etc/shorewall/shorewall.conf, you can cause +Shorewall to create an alias label of the form interfacename:digit + (e.g., eth0:0) by placing that label in this column. +See example 5 below. Alias labels created in this way allow the +alias to be visible to the ipconfig utility. THAT IS THE ONLY +THING THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE +IN YOUR SHOREWALL CONFIGURATION.
    • +
  • 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. When using Shorewall 1.3.13 or earlier, when an interface + name is specified, Shorewall will only masquerade traffic from + the first subnetwork on the named interface; if the interface interfaces + to more that one subnetwork, you will need to add additional entries + to this file for each of those other subnetworks. Beginning with +Shorewall 1.3.14, shorewall will masquerade/SNAT traffic from any +host that is routed through the named interface.
    +
    + 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. If you specify an address in this column, it +must be an IP address configured on the INTERFACE or you must have +ADD_SNAT_ALIASES enabled in /etc/shorewall/shorewall.conf.
    • +
- +

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.

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

- -
+ 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
+ INTERFACE + SUBNETADDRESS
eth0192.168.10.0/24206.124.146.176
-
- +
+

Example 4: Same as example 3 except that - you wish to exclude 192.168.10.44 - and 192.168.10.45 from - the SNAT rule.

- -
+ you wish to exclude + 192.168.10.44 and 192.168.10.45 from + 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
-
- Example 5 (Shorewall version >= 1.3.14): You - have a second IP address (206.124.146.177) assigned to you and -wish to use it for SNAT of the subnet 192.168.12.0/24. You want to -give that address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes - in /etc/shorewall/shorewall.conf.
- -
+
+ Example 5 (Shorewall version >= 1.3.14): + You have a second IP address (206.124.146.177) assigned + to you and wish to use it for SNAT of the subnet 192.168.12.0/24. + You want to give that address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes + in /etc/shorewall/shorewall.conf.
+ +
+ - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
INTERFACE SUBNETADDRESS
eth0:0192.168.12.0/24206.124.146.177
+ INTERFACE + SUBNETADDRESS
eth0:0192.168.12.0/24206.124.146.177
-
- +
+

/etc/shorewall/proxyarp

- +

If you want to use proxy ARP on an entire sub-network, - I suggest that you - look at 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 enabling @@ -2211,792 +2478,844 @@ of systems since you need one entry in this file for each system using proxy ARP. Columns - are:

- + 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 while to time out. I personally have had to contact my ISP and ask them 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:

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

+

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.

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

- + 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 all you want to do - is forward ports - to servers behind your firewall, - you do NOT want to use - static NAT. Port - forwarding can - be accomplished - with simple entries in - the - 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.

- + is forward ports + to servers behind your firewall, + you do NOT want to use + static NAT. Port + forwarding + can be +accomplished with simple entries +in the + 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. Beginning with Shorewall version 1.3.14, if you have set -ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf, -  you can specify an alias label of the form interfacename:digit - (e.g., eth0:0) and Shorewall will create the alias with that -label. Alias labels created in this way allow the alias to be visible -to the ipconfig utility. THAT IS THE ONLY THING THAT THIS LABEL -IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION. 
    • -
  • 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.
    • -
  • 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. Beginning with Shorewall version 1.3.14, if +you have set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf, +  you can specify an alias label of the form interfacename:digit + (e.g., eth0:0) and Shorewall will create the alias with + that label. Alias labels created in this way allow the alias +to be visible to the ipconfig utility. THAT IS THE ONLY THING + THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN +YOUR SHOREWALL CONFIGURATION. 
    • +
  • 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.
    • +
  • 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, - OpenVPN, PPTP - and 6to4.tunnels with end-points on your firewall. To use ipsec, - you must install version 1.9, 1.91 or the current OpenVPN, PPTP + and 6to4.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, instructions for OpenVPN tunnels are here, - instructions for PPTP tunnels are here - and instructions for 6to4 tunnels are here.

- + be found here, instructions for IPIP and GRE tunnels +are here, instructions for OpenVPN tunnels +are here, instructions for PPTP +tunnels are here and instructions for 6to4 +tunnels are here.

+

/etc/shorewall/shorewall.conf

- +

This file is used to set the following firewall parameters:

- +
    -
  • LOGFORMAT - - Added at version 1.4.4.
    - The value of this variable generate the --log-prefix setting for Shorewall - logging rules. It contains a 'printf' formatting template which accepts three - arguments (the chain name, logging rule number (optional) and the disposition). - To use LOGFORMAT with fireparse (http://www.fireparse.com), - set it as:
    -  
    -        LOGFORMAT="fp=%s:%d a=%s "
    -  
    - If the LOGFORMAT value contains the substring '%d' then the logging rule - number is calculated and formatted in that position; if that substring is - not included then the rule number is not included. If not supplied or supplied - as empty (LOGFORMAT="") then "Shorewall:%s:%s:" is assumed.
    -
    - CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT - string (up to but not including the first '%') to find log messages in -the 'show log', 'status' and 'hits' commands. This part should not be omitted - (the LOGFORMAT should not begin with "%") and the leading part should be - sufficiently unique for /sbin/shorewall to identify Shorewall messages.
    -
    • -
  • CLEAR_TC - Added at version 1.3.13
    - If this option is set to 'No' then Shorewall won't - clear the current traffic control rules during [re]start. This - setting is intended for use by people that prefer to configure traffic - shaping when the network interfaces come up rather than when the -firewall is started. If that is what you want to do, set TC_ENABLED=Yes -and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. -That way, your traffic shaping rules can still use the 'fwmark' classifier - based on packet marking defined in /etc/shorewall/tcrules. If not specified, - CLEAR_TC=Yes is assumed.
    -
    • -
  • 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 SHOREWALL_SHELL + - Added at version 1.4.6
    + This parameter is used to specify the shell program to be used to interpret + the firewall script (/usr/share/shorewall/firewall). If not specified or + specified as a null value, /bin/sh is assumed.
    +
    • +
  • LOGFORMAT - Added at version 1.4.4.
    + The value of this variable generate the --log-prefix setting +for Shorewall logging rules. It contains a 'printf' formatting template +which accepts three arguments (the chain name, logging rule number (optional) + and the disposition). To use LOGFORMAT with fireparse (    http://www.fireparse.com), set it as:
    +  
    +        LOGFORMAT="fp=%s:%d a=%s "
    +  
    + If the LOGFORMAT value contains the substring '%d' then the +logging rule number is calculated and formatted in that position; if +that substring is not included then the rule number is not included. +If not supplied or supplied as empty (LOGFORMAT="") then "Shorewall:%s:%s:" + is assumed.
    +
    + CAUTION: /sbin/shorewall uses the leading part +of the LOGFORMAT string (up to but not including the first '%') to +find log messages in the 'show log', 'status' and 'hits' commands. This +part should not be omitted (the LOGFORMAT should not begin with "%") +and the leading part should be sufficiently unique for /sbin/shorewall +to identify Shorewall messages.
    +
    • +
  • CLEAR_TC - Added at version 1.3.13
    + If this option is set to 'No' then Shorewall + won't clear the current traffic control rules during [re]start. + This setting is intended for use by people that prefer to configure + traffic shaping when the network interfaces come up rather +than when the firewall is started. If that is what you want to do, +set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart + file. That way, your traffic shaping rules can still use the 'fwmark' + classifier based on packet marking defined in /etc/shorewall/tcrules. + If not specified, CLEAR_TC=Yes is assumed.
    +
    • +
  • 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.
    -
    • -
  • RFC1918_LOG_LEVEL - Added at - version 1.3.12
    - This parameter determines the level at -which packets logged under the +
    • +
  • 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 +
  • 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 +
  • 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 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 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.
    -
    • -
  • 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.
    • + 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.
    +
    • +
  • 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.
    • -
  • DETECT_DNAT_ADDRS - Added in Version 1.3.4
    - If set to "Yes" or "yes", Shorewall will detect the -first IP address of the interface to the source zone and will include - this address in DNAT rules as the original destination IP address. - If set to "No" or "no", Shorewall will not detect this address - 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:
    +
  • DETECT_DNAT_ADDRS - Added in Version 1.3.4
    + If set to "Yes" or "yes", Shorewall will detect + the first IP address of the interface to the source zone and +will include this address in DNAT rules as the original destination + IP address. If set to "No" or "no", Shorewall will not detect + this address and any destination IP address will match the + DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes" + is assumed.
    +
    • +
  • MULTIPORT + - (Removed in version 1.4.6 -- the value of this parameter is now automatically + detected by Shorewall)
    + 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
    -     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.
    • -
  • 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.
    -
    • -
  • 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. RESTRICTION: Shorewall can only add addresses - to the first subnetwork configured on an interface.
    -
    - 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. RESTRICTION: Shorewall -can only add addresses to the first subnetwork configured on an interface.
    -
    - 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 ' +
    • +
  • 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. +
    • +
  • 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 + (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically + detected by Shorewall)
    + 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 + (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically + detected by Shorewall)
    + 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. RESTRICTION: Shorewall versions before +1.4.6 can only add addresses to the first subnetwork configured on +an interface.
    +
    + 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. RESTRICTION: + Shorewall versions before 1.4.6 can only add addresses to +the first subnetwork configured on an interface.
    +
    + 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 - 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 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".
    • - + 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 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".
    • +
- +

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

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

-
- + <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 - modules and execute the following command:

- -
+ modules and execute the following command:

+ +
+

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

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 @@ -3006,9 +3325,9 @@ type of service. Must be one of the following: or subnet address. Example:

- + 
      130.252.100.69
      206.124.146.0/24
- +

Packets from hosts listed @@ -3034,121 +3353,130 @@ type of service. Must be one of the following: are checked against 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").
    -
    • - -
- -

Shorewall also has a dynamic blacklist - 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).

- -

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

- -
    -
  • 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 -- see the RFC1918_LOG_LEVEL - parameter above.
      • - - -
    +
  • 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").
    • - +
- -

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

- + +

Shorewall also has a dynamic blacklist + 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). +

+ +

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

+ +
+ - - - - - - - - - - - - - + + + + + + + + + + + + + - - + + +
INTERFACEHOST(S)
eth2192.168.1.0/24
eth1-
INTERFACEHOST(S)
eth2192.168.1.0/24
eth1-
-
- +
+

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

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

/etc/shorewall/ecn (Added in Version 1.4.0)

- This file is described in the ECN Control Documentation.
- -

Updated 6/2/2003 - Tom Eastep -

- + This file is described +in the ECN Control Documentation.
+ +

Updated 6/28/2003 - Tom Eastep +

+

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

+

+
+


diff --git a/STABLE/documentation/ECN.html b/STABLE/documentation/ECN.html index c2ebd20ed..e50fd131c 100644 --- a/STABLE/documentation/ECN.html +++ b/STABLE/documentation/ECN.html @@ -2,82 +2,90 @@ Shorewall and ECN + + - + + - - - + + - - - + + + +
+ bgcolor="#3366ff" height="90"> +

ECN

-
-
-Explicit Congestion Notification (ECN) is described in RFC 3168 and is a -proposed internet standard. Unfortunately, not all sites support ECN and -when a TCP connection offering ECN is sent to sites that don't support it, -the result is often that the connection request is ignored.
-
-To allow ECN to be used, Shorewall allows you to enable ECN on your Linux -systems then disable it in your firewall when the destination matches a list +
+ Explicit Congestion Notification (ECN) is described in RFC 3168 and is a +proposed internet standard. Unfortunately, not all sites support ECN and when +a TCP connection offering ECN is sent to sites that don't support it, the +result is often that the connection request is ignored.
+
+ To allow ECN to be used, Shorewall allows you to enable ECN on your Linux +systems then disable it in your firewall when the destination matches a list that you create (the /etc/shorewall/ecn file).
-
-You enable ECN by
-
-
- 
echo 1 > /proc/sys/net/ipv4/tcp_ecn
-
-You must arrange for that command to be executed at system boot. Most distributions -have a method for doing that -- on RedHat, you make an entry in /etc/sysctl.conf.
-
-
- 
net.ipv4.tcp_ecn = 1

-
-Entries in /etc/shorewall/ecn have two columns as follows:
-
-INTERFACE    - The name of an interface on your system
-
-HOST(S)        - An address (host or subnet) -of a system or group of systems accessed through the  interface in the -first column. You may include a comma-separated list of such addresses in -this column.
-
-Example: Your external interface is eth0 and you want to disable ECN for -tcp connections to 192.0.2.0/24:
-
-In /etc/shorewall/ecn:
-
-
- - - - - - - - - - - -
INTERFACE
- 		HOST(S)
-
eth0
- 		192.0.2.0/24
-
-
-
-Last updated 3/28/2003 - Tom Eastep +
+ You enable ECN by
+
+
+ 
echo 1 > /proc/sys/net/ipv4/tcp_ecn
+
+ You must arrange for that command to be executed at system boot. Most distributions +have a method for doing that -- on RedHat, you make an entry in /etc/sysctl.conf.
+
+ +
+ 
net.ipv4.tcp_ecn = 1

+
+ Entries in /etc/shorewall/ecn have two columns as follows:
+
+ INTERFACE    - The name of an interface on your system
+
+ HOST(S)        - An address (host or subnet) +of a system or group of systems accessed through the  interface in the +first column. You may include a comma-separated list of such addresses in +this column.
+
+ Example: Your external interface is eth0 and you want to disable ECN for +tcp connections to 192.0.2.0/24:
+
+ In /etc/shorewall/ecn:
+
+ +
+ + + + + + + + + + + + +
INTERFACE
+ 		HOST(S)
+
eth0
+ 		192.0.2.0/24
+
+
+
+ Last updated 3/28/2003 - Tom Eastep +

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

+

+
diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index 5bb4fddd7..6413295ba 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -1,1301 +1,1395 @@ - + - + - + - + Shorewall FAQ - + + - + - - - + + - - - + + + +
+ bgcolor="#3366ff" height="90"> +
+

Shorewall FAQs

-
- +

Looking for Step by Step Configuration Instructions? Check out the QuickStart Guides.
-

- -

PORT FORWARDING
-

- -

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

- -

1c. From the internet, I want to -connect to port 1022 on my firewall and have the firewall forward -the connection to port 22 on local system 192.168.1.3. How do I do that?
-

- -

DNS and PORT FORWARDING/NAT
-

- -

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.

- -

NETMEETING/MSN
-

- -

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

- -

OPEN PORTS
-

- -

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

- 4b. I have a port that I can't close no matter -how I change my rules.  -

CONNECTION PROBLEMS

- -

5. I've installed Shorewall and now - I can't ping through the firewall
-
- 15. My local systems can't see - out to the net

- -

LOGGING
-

- -

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

- -

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

- -

6b. DROP messages on port 10619 are flooding the logs with their connect - requests. Can i exclude these error messages for this port temporarily - from logging in Shorewall?
-

- -

6c. All day long I get a steady flow - of these DROP messages from port 53 to some high numbered - port. They get dropped, but what the heck are they?
-

- -

6d. Why is the MAC address - in Shorewall log messages so long? I thought MAC addresses - were only 6 bytes in length.
-

- -

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?
-
- 21. I see these strange log entries - occasionally; what are they?
- -

STARTING AND STOPPING
-

- -

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

- -

8a. When I try to start Shorewall - on RedHat I get a message referring me to FAQ #8
-

- -

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

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

ABOUT SHOREWALL
-

- -

10. What distributions does - it work with?

- -

11. What features does it support?

- -

12. Is there a GUI?

- -

13. Why do you call it "Shorewall"?

- 23. Why do you -use such ugly fonts on your web site?
-
- 25. How to I tell which version of Shorewall - I am running?
- -

RFC 1918
-

- -

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.

- -

ALIAS IP ADDRESSES/VIRTUAL INTERFACES
-

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

MISCELLANEOUS

- 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?
-
- 24. How can I allow - conections to let's say the ssh port only from specific - IP Addresses on 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.

- + +

PORT FORWARDING
+

+ +

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

+ +

1c. From the internet, I want to connect +to port 1022 on my firewall and have the firewall forward the connection +to port 22 on local system 192.168.1.3. How do I do that?
+

+ +

DNS and PORT FORWARDING/NAT
+

+ +

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.

+ +

NETMEETING/MSN
+

+ +

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

+ +

OPEN PORTS
+

+ +

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

+ 4b. I have a port that I can't close no +matter how I change my rules.
+
+ 4c. How to I use Shorewall with PortSentry?
+ +

CONNECTION PROBLEMS

+ +

5. I've installed Shorewall and now + I can't ping through the firewall
+
+ 15. My local systems can't see + out to the net

+ +

LOGGING
+

+ +

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

+ +

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

+ +

6b. DROP messages on port 10619 are flooding the logs with their connect + requests. Can i exclude these error messages for this port + temporarily from logging in Shorewall?
+

+ +

6c. All day long I get a steady flow + of these DROP messages from port 53 to some high + numbered port. They get dropped, but what the heck are + they?
+

+ +

6d. Why is the MAC address + in Shorewall log messages so long? I thought MAC addresses + were only 6 bytes in length.
+

+ +

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?
+
+ 21. I see these strange log + entries occasionally; what are they?
+ +

STARTING AND STOPPING
+

+ +

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

+ +

8a. When I try to start Shorewall + on RedHat I get a message referring me to FAQ #8
+

+ +

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

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

ABOUT SHOREWALL
+

+ +

10. What distributions does + it work with?

+ +

11. What features does it +support?

+ +

12. Is there a GUI?

+ +

13. Why do you call it "Shorewall"?

+ 23. Why +do you use such ugly fonts on your web site?
+
+ 25. How to I tell which version +of Shorewall I am running?
+ +

RFC 1918
+

+ +

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.

+ +

ALIAS IP ADDRESSES/VIRTUAL INTERFACES
+

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

MISCELLANEOUS
+

+ 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?
+
+ 24. How can +I allow conections to let's say the ssh port only + from specific IP Addresses on the internet?
+
+ 26. When I try to use any +of the SYN options in nmap on or behind the firewall, I get "operation + not permitted". How can I use nmap with Shorewall?"
+
+ 27. I am compiling a new kernel for my +firewall. What should I look out for?
+
+ 28. How do I use Shorewall as a Bridging Firewall?
+ +
+

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 +
+ 		+
+
-
- -
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>
-
- Finally, if you need to forward a range of ports, -in the PORT column specify the range as low-port:high-port.
- -

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

- -

Answer: That is usually the result of one of three - things:

- +
+ Finally, if you need to forward a range of +ports, in the PORT column specify the range as low-port:high-port.
+ +

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

+ +

Answer: That is usually the result of one of three + 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).
    • -
  • Your ISP is blocking that particular port inbound.
    -
    • - +
  • 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).
    • +
  • Your ISP is blocking that particular port inbound.
    +
    • +
- -

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 <source - zone>_dnat ('net_dnat' 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 + <source zone>_dnat ('net_dnat' 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.
      +
      • +
    - +
- -

1c. From the internet, I want - to connect to port 1022 on my firewall and have the firewall forward the - connection to port 22 on local system 192.168.1.3. How do I do that?

- -
-
+ +

1c. From the internet, I want + to connect to port 1022 on my firewall and have the firewall forward + the connection to port 22 on local system 192.168.1.3. How do I do +that?

+ +
+
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
DNATnet
- 		loc:192.168.1.3:22tcp1022
-
-
-
-
-
- -

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.

+ + + ACTION + SOURCE + DESTINATION + PROTOCOL + PORT + SOURCE + PORT + ORIG. + DEST. + + + DNAT + net
+ + loc:192.168.1.3:22 + tcp + 1022
+ +
+ +
+ + + + + +
+
+ +

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

- + +

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

+

If you are running Shorewall 1.4.0 or earlier see the 1.3 FAQ for instructions suitable for those -releases.
-

- -

If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please - upgrade to Shorewall 1.4.2 or later.
-

- + href="1.3/FAQ.htm#faq2">the 1.3 FAQ for instructions suitable for +those releases.
+

+ +

If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please + upgrade to Shorewall 1.4.2 or later.
+

+

Otherwise:
-

- +

+
    - +
- +
    - +
- +
    -
  • In /etc/shorewall/interfaces:
    • - +
  • In /etc/shorewall/interfaces:
    • +
- -
+ +
- - - - - - - - - - - - - - - + + + + + + + + + + + + + + + +
ZONE
- 		INTERFACE
- 		BROADCAST
- 		OPTIONS
-
loc
- 		eth1
- 		detect
- 		routeback
-
ZONE
+ 		INTERFACE
+ 		BROADCAST
+ 		OPTIONS
+
loc
+ 		eth1
+ 		detect
+ 		routeback
+
-
- +
+
    - +
- +
    -
  • In /etc/shorewall/rules:
    • - +
  • In /etc/shorewall/rules:
    • +
- -
+ +
- - - - - - - - + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
+
ACTIONSOURCEDEST PROTODEST
PORT(S)		ORIGINAL
- DEST
DNAT
- 		locweb:192.168.1.5
- 		tcpwww -
- 		130.151.100.69:192.168.1.254
-
SOURCE
+ PORT(S)		ORIGINAL
+ DEST
DNAT
+ 		locweb:192.168.1.5
+ 		tcpwww -
+ 		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/init:

-
- -
+
+ +
+

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/init:

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

and make your DNAT rule:

-
- -
-
+
+ +
+
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
DNATlocweb:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE + PORTORIG. + DEST.
DNATlocweb: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:

- + + + +
+

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

- + b) 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.255
-
ZONEINTERFACEBROADCASTOPTIONS
dmzeth2192.168.2.255
+
-
- +
+

In /etc/shorewall/policy:

- -
+ +
- - - - - - - - - - - - - - - -
SOURCE - DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
-
-
- -

In /etc/shorewall/masq:

+ + + SOURCE + + DESTINATION + POLICY + LIMIT:BURST + + + dmz + dmz + ACCEPT + +
+ + + -
+ + +
+ +

In /etc/shorewall/masq:

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

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

- +
+ +

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

+

Answer: There is an H.323 connection - tracking/NAT module that may help with Netmeeting. - Look here for a - solution for MSN IM but be aware that there are significant security - risks involved with this solution. Also check the Netfilter mailing + href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection + tracking/NAT module that may help with + Netmeeting. Look here for a solution + for MSN IM but be aware that there are significant security risks +involved with this solution. Also check the Netfilter mailing list archives at http://www.netfilter.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.
-

- -

4b. I have a port that I can't close no matter how - I change my rules. 

- I had a rule that allowed telnet from my local network to my firewall; -I removed that rule and restarted Shorewall but my telnet session still works!!!
-
- Answer:  Rules only govern the establishment of new connections. - Once a connection is established through the firewall it will be usable -until disconnected (tcp) or until it times out (other protocols).  If you -stop telnet and try to establish a new session your firerwall will block -that attempt.
- -

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) Create /etc/shorewall/common if it doesn't already exist. -
- b) Be sure that - the first command in the file is ". /etc/shorewall/common.def"
- c) Add the following - to /etc/shorewall/common

- -
-

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:

- -
+

+ +

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

+ +

4b. I have a port that I can't close no matter how + I change my rules. 

+ I had a rule that allowed telnet from my local network to my firewall; + I removed that rule and restarted Shorewall but my telnet session still + works!!!
+
+ Answer:  Rules only govern the establishment of new connections. + Once a connection is established through the firewall it will be usable + until disconnected (tcp) or until it times out (other protocols).  If you + stop telnet and try to establish a new session your firerwall will block + that attempt.
+ +

4c. How to I use Shorewall with +PortSentry?

+ Here's +a writeup on a nice integration of Shorewall and PortSentry.
+ +

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) Create /etc/shorewall/common if it doesn't already exist. +
+ b) Be sure + that the first command in the file is ". /etc/shorewall/common.def"
+ c) Add +the following to /etc/shorewall/common

+ +
+

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

- -
+ 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/fwlogwatch
- http://www.logwatch.org
- http://gege.org/iptables
-

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

6b. DROP messages on port 10619 - are flooding the logs with their connect requests. Can - i exclude these error messages for this port temporarily from logging - in Shorewall?

- Temporarily add the following rule:
- + http://www.logwatch.org
+ http://gege.org/iptables
+

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

6b. DROP messages on port 10619 + are flooding the logs with their connect requests. + Can i exclude these error messages for this port temporarily +from logging in Shorewall?

+ Temporarily add the following rule:
+ 
	DROP    net    fw    udp    10619
- -

6c. All day long I get a steady flow - of these DROP messages from port 53 to some high numbered port. - They get dropped, but what the heck are they?

- + +

6c. All day long I get a steady flow + of these DROP messages from port 53 to some high numbered + port. They get dropped, but what the heck are they?

+ 
Jan  8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00
                                                        SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00
                                                        TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33
- Answer: There are two possibilities:
- + Answer: There are two possibilities:
+
    -
  1. They are late-arriving replies to DNS queries.
    2. -
  2. They are corrupted reply packets.
    3. - +
  3. They are late-arriving replies to +DNS queries.
    4. +
  4. They are corrupted reply packets.
    5. +
- You can distinguish the difference by setting -the logunclean option (/etc/shorewall/interfaces) - on your external interface (eth0 in the above example). If they get - logged twice, they are corrupted. I solve this problem by using - an /etc/shorewall/common file like this:
- -
+ You can distinguish the difference by setting + the logunclean option (/etc/shorewall/interfaces) + on your external interface (eth0 in the above example). If they get + logged twice, they are corrupted. I solve this problem by using + an /etc/shorewall/common file like this:
+ +
#
# Include the standard common.def file
#
. /etc/shorewall/common.def
#
# The following rule is non-standard and compensates for tardy
# DNS replies
#
run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
-
- The above file is also include in all of my sample - configurations available in the Quick Start Guides and in - the common.def file in Shorewall 1.4.0 and later.
- -

6d. Why is the MAC address in - Shorewall log messages so long? I thought MAC addresses were only - 6 bytes in length.

- What is labeled as the MAC address in a Shorewall log message - is actually the Ethernet frame header. IT contains:
- +
+ The above file is also include in all of + my sample configurations available in the Quick Start Guides and in + the common.def file in Shorewall 1.4.0 and later.
+ +

6d. Why is the MAC address in + Shorewall log messages so long? I thought MAC addresses were + only 6 bytes in length.

+ What is labeled as the MAC address in a Shorewall log + message is actually the Ethernet frame header. IT contains:
+
    -
  • the destination MAC address (6 bytes)
    • -
  • the source MAC address (6 bytes)
    • -
  • the ethernet frame type (2 bytes)
    • - +
  • the destination MAC address (6 bytes)
    • +
  • the source MAC address (6 bytes)
    • +
  • the ethernet frame type (2 bytes)
    • +
- Example:
-
- MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
- + Example:
+
+ MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
+
    -
  • Destination MAC address = 00:04:4c:dc:e2:28
    • -
  • Source MAC address = 00:b0:8e:cf:3c:4c
    • -
  • Ethernet Frame Type = 08:00 (IP Version 4)
    • - +
  • Destination MAC address = 00:04:4c:dc:e2:28
    • +
  • Source MAC address = 00:b0:8e:cf:3c:4c
    • +
  • Ethernet Frame Type = 08:00 (IP Version +4)
    • +
- -

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:

- + +

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

- -

8a. When I try to start Shorewall on RedHat - I get a message referring me to FAQ #8

- Answer: This is usually cured by the sequence of commands - shown above in FAQ #8 -
- -

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

- -

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

- -
+
+ +
+

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

+ +

8a. When I try to start Shorewall on RedHat + I get a message referring me to FAQ #8

+ Answer: This is usually cured by the sequence of + commands shown above in FAQ #8 +
+ +

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

+ +

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

+ +
     Processing /etc/shorewall/params ...
     Processing /etc/shorewall/shorewall.conf ...
     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 + +

+ +

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. Is there a GUI?

- -

Answer: Yes. Shorewall support is included in Webmin - 1.060 and later versions. See http://www.webmin.com -

- + +

Answer: Yes. Shorewall support is included in Webmin + 1.060 and later versions. See http://www.webmin.com

+

13. Why do you call it "Shorewall"?

- -

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:

- -
+ +

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

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

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

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: If you are running Shorewall version 1.4.4 -or 1.4.4a then check the errata. Otherwise, see -the 'dmesg' man page ("man dmesg"). You must 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:
- + +

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

+ +

Answer: If you are running Shorewall version 1.4.4 + or 1.4.4a then check the errata. Otherwise, see + the 'dmesg' man page ("man dmesg"). You must 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 + or logdrop - The destination address is + listed in /etc/shorewall/rfc1918 with a logdrop target + -- see /etc/shorewall/rfc1918.
    2. +
  2. rfc1918 + or logdrop - The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
    3. -
  3. rfc1918 - - The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see /etc/shorewall/rfc1918.
    4. -
  4. 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.
    -
    5. -
  5. <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.
    6. -
  6. <interface>_mac - - The packet is being logged under the maclist - interface option.
    -
    7. -
  7. logpkt -- The packet is being logged under the logunclean - interface option.
    8. -
  8. 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.
    +
    9. +
  9. <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.
    10. +
  10. <interface>_mac + - The packet is being logged under the maclist + interface option.
    +
    11. +
  11. logpkt + - The packet is being logged under the logunclean + interface option.
    12. +
  12. badpkt + - The packet is being logged under the + dropunclean interface option as specified + in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    13. -
  13. blacklst - - The packet is being logged because the source IP - is blacklisted in the /etc/shorewall/blacklist - file.
    14. -
  14. 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.
    15. -
  15. 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.
    16. -
  16. logflags - The packet - is being logged because it failed the checks implemented - by the tcpflags 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. See -Shorewall and Aliased Interfaces. - -

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

- -
+ +

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

+ Answer: Yes. + See Shorewall and Aliased + Interfaces. +

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

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

23. Why do you use such ugly fonts on your - web site?

- The Shorewall web site is almost font neutral - (it doesn't explicitly specify fonts except on a few pages) -so the fonts you see are largely the default fonts configured in -your browser. If you don't like them then reconfigure your browser.
- -

24. How can I allow conections to let's say - the ssh port only from specific IP Addresses on the internet?

- In the SOURCE column of the rule, follow "net" - by a colon and a list of the host/subnet addresses as a comma-separated - list.
- +
+ 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.
+ +

23. Why do you use such ugly fonts on your + web site?

+ The Shorewall web site is almost +font neutral (it doesn't explicitly specify fonts except +on a few pages) so the fonts you see are largely the default fonts +configured in your browser. If you don't like them then reconfigure + your browser.
+ +

24. How can I allow conections to let's say + the ssh port only from specific IP Addresses on +the internet?

+ In the SOURCE column of the rule, follow + "net" by a colon and a list of the host/subnet addresses as + a comma-separated list.
+ 
    net:<ip1>,<ip2>,...
- Example:
- + Example:
+ 
    ACCEPT	net:192.0.2.16/28,192.0.2.44	fw	tcp	22
- +
- -

25. How to I tell which version of Shorewall - I am running?
-

- At the shell prompt, type:
-
- /sbin/shorewall version
+ +

25. How to I tell which version of Shorewall + I am running?
+

+ At the shell prompt, type:
+
+ /sbin/shorewall version
+ +

26. When I try to use any of the SYN options + in nmap on or behind the firewall, I get "operation not permitted". How + can I use nmap with Shorewall?"

+ Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes" + then restart Shorewall.
+ +

27. I'm compiling a new kernel for my firewall. What +should I look out for?

+ First take a look at the Shorewall kernel configuration + page. You probably also want to be sure that you have selected the +"NAT of local connections (READ HELP)" on the Netfilter Configuration +menu. Otherwise, DNAT rules with your firewall as the source zone won't +work with your new kernel.
+ +

28. How do I use Shorewall as a Bridging Firewall?
+

+ Basically, you don't. While there are kernel patches that allow you to + route bridge traffic through Netfilter, the environment is so different +from the Layer 3 firewalling environment that very little of Shorewall works. +In fact, so much of Shorewall doesn't work that my official position is that + "Shorewall doesn't work with Layer 2 Bridging".

- Last updated 5/29/2003 - Tom Eastep + Last updated 7/9/2003 - Tom Eastep

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

+

+
+
+
+
+
+
+
diff --git a/STABLE/documentation/Forum.html b/STABLE/documentation/Forum.html index 188976791..2247535e9 100644 --- a/STABLE/documentation/Forum.html +++ b/STABLE/documentation/Forum.html @@ -1,42 +1,45 @@ - + Shorewall Support Forum - + - + - + - - - + + - - - + + + +
+ id="AutoNumber1" bgcolor="#3366ff" height="90"> +

Support Forum

-
- +

-

REPORTING A PROBLEM OR ASKING FOR HELP? If you haven't already, please + +

REPORTING A PROBLEM OR ASKING FOR HELP? If you haven't already, please read the Shorewall Support Guide.

-

Shorewall Support + +

Shorewall Support Forum
-

- -

Updated 3/6/2003 - Tom Eastep +

+ +

Updated 3/6/2003 - Tom Eastep

- +

Copyright © 2003 Thomas M. Eastep.

-
+
+
diff --git a/STABLE/documentation/GnuCopyright.htm b/STABLE/documentation/GnuCopyright.htm index 59961611a..ef2028032 100644 --- a/STABLE/documentation/GnuCopyright.htm +++ b/STABLE/documentation/GnuCopyright.htm @@ -1,282 +1,341 @@ + - - - - - -Copyright + + + + + + + + + Copyright - - - - - - - + + +
-

GNU Free Documentation License

-
+ + + + + +
+

GNU Free Documentation License

+
+

Version 1.1, March 2000

-
Copyright (C) 2000  Free Software Foundation, Inc.
-59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-Everyone is permitted to copy and distribute verbatim copies
-of this license document, but changing it is not allowed.
-
+ +
Copyright (C) 2000  Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
+

0. PREAMBLE

-

The purpose of this License is to make a manual, textbook, or other written -document "free" in the sense of freedom: to assure everyone the effective -freedom to copy and redistribute it, with or without modifying it, either -commercially or noncommercially. Secondarily, this License preserves for the -author and publisher a way to get credit for their work, while not being + +

The purpose of this License is to make a manual, textbook, or other written +document "free" in the sense of freedom: to assure everyone the effective +freedom to copy and redistribute it, with or without modifying it, either +commercially or noncommercially. Secondarily, this License preserves for +the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

-

This License is a kind of "copyleft", which means that derivative works of -the document must themselves be free in the same sense. It complements the GNU -General Public License, which is a copyleft license designed for free software. -

-

We have designed this License in order to use it for manuals for free -software, because free software needs free documentation: a free program should -come with manuals providing the same freedoms that the software does. But this -License is not limited to software manuals; it can be used for any textual work, -regardless of subject matter or whether it is published as a printed book. We -recommend this License principally for works whose purpose is instruction or -reference.

+ +

This License is a kind of "copyleft", which means that derivative works +of the document must themselves be free in the same sense. It complements +the GNU General Public License, which is a copyleft license designed for +free software.

+ +

We have designed this License in order to use it for manuals for free software, +because free software needs free documentation: a free program should come +with manuals providing the same freedoms that the software does. But this +License is not limited to software manuals; it can be used for any textual +work, regardless of subject matter or whether it is published as a printed +book. We recommend this License principally for works whose purpose is instruction +or reference.

+

1. APPLICABILITY AND DEFINITIONS

-

This License applies to any manual or other work that contains a notice -placed by the copyright holder saying it can be distributed under the terms of -this License. The "Document", below, refers to any such manual or work. Any -member of the public is a licensee, and is addressed as "you".

-

A "Modified Version" of the Document means any work containing the Document -or a portion of it, either copied verbatim, or with modifications and/or -translated into another language.

-

A "Secondary Section" is a named appendix or a front-matter section of the -Document that deals exclusively with the relationship of the publishers or -authors of the Document to the Document's overall subject (or to related -matters) and contains nothing that could fall directly within that overall -subject. (For example, if the Document is in part a textbook of mathematics, a -Secondary Section may not explain any mathematics.) The relationship could be a -matter of historical connection with the subject or with related matters, or of -legal, commercial, philosophical, ethical or political position regarding them. -

-

The "Invariant Sections" are certain Secondary Sections whose titles are -designated, as being those of Invariant Sections, in the notice that says that -the Document is released under this License.

-

The "Cover Texts" are certain short passages of text that are listed, as -Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document -is released under this License.

-

A "Transparent" copy of the Document means a machine-readable copy, -represented in a format whose specification is available to the general public, -whose contents can be viewed and edited directly and straightforwardly with -generic text editors or (for images composed of pixels) generic paint programs -or (for drawings) some widely available drawing editor, and that is suitable for -input to text formatters or for automatic translation to a variety of formats -suitable for input to text formatters. A copy made in an otherwise Transparent -file format whose markup has been designed to thwart or discourage subsequent -modification by readers is not Transparent. A copy that is not "Transparent" is -called "Opaque".

-

Examples of suitable formats for Transparent copies include plain ASCII -without markup, Texinfo input format, LaTeX input format, SGML or XML using a -publicly available DTD, and standard-conforming simple HTML designed for human -modification. Opaque formats include PostScript, PDF, proprietary formats that -can be read and edited only by proprietary word processors, SGML or XML for -which the DTD and/or processing tools are not generally available, and the -machine-generated HTML produced by some word processors for output purposes -only.

-

The "Title Page" means, for a printed book, the title page itself, plus such -following pages as are needed to hold, legibly, the material this License -requires to appear in the title page. For works in formats which do not have any -title page as such, "Title Page" means the text near the most prominent -appearance of the work's title, preceding the beginning of the body of the text. -

+ +

This License applies to any manual or other work that contains a notice +placed by the copyright holder saying it can be distributed under the terms +of this License. The "Document", below, refers to any such manual or work. +Any member of the public is a licensee, and is addressed as "you".

+ +

A "Modified Version" of the Document means any work containing the Document +or a portion of it, either copied verbatim, or with modifications and/or translated +into another language.

+ +

A "Secondary Section" is a named appendix or a front-matter section of +the Document that deals exclusively with the relationship of the publishers +or authors of the Document to the Document's overall subject (or to related +matters) and contains nothing that could fall directly within that overall +subject. (For example, if the Document is in part a textbook of mathematics, +a Secondary Section may not explain any mathematics.) The relationship could +be a matter of historical connection with the subject or with related matters, +or of legal, commercial, philosophical, ethical or political position regarding +them.

+ +

The "Invariant Sections" are certain Secondary Sections whose titles are +designated, as being those of Invariant Sections, in the notice that says +that the Document is released under this License.

+ +

The "Cover Texts" are certain short passages of text that are listed, +as Front-Cover Texts or Back-Cover Texts, in the notice that says that the +Document is released under this License.

+ +

A "Transparent" copy of the Document means a machine-readable copy, represented +in a format whose specification is available to the general public, whose +contents can be viewed and edited directly and straightforwardly with generic +text editors or (for images composed of pixels) generic paint programs or +(for drawings) some widely available drawing editor, and that is suitable +for input to text formatters or for automatic translation to a variety of +formats suitable for input to text formatters. A copy made in an otherwise +Transparent file format whose markup has been designed to thwart or discourage +subsequent modification by readers is not Transparent. A copy that is not +"Transparent" is called "Opaque".

+ +

Examples of suitable formats for Transparent copies include plain ASCII +without markup, Texinfo input format, LaTeX input format, SGML or XML using +a publicly available DTD, and standard-conforming simple HTML designed for +human modification. Opaque formats include PostScript, PDF, proprietary formats +that can be read and edited only by proprietary word processors, SGML or +XML for which the DTD and/or processing tools are not generally available, +and the machine-generated HTML produced by some word processors for output +purposes only.

+ +

The "Title Page" means, for a printed book, the title page itself, plus +such following pages as are needed to hold, legibly, the material this License +requires to appear in the title page. For works in formats which do not have +any title page as such, "Title Page" means the text near the most prominent +appearance of the work's title, preceding the beginning of the body of the +text.

+

2. VERBATIM COPYING

-

You may copy and distribute the Document in any medium, either commercially -or noncommercially, provided that this License, the copyright notices, and the -license notice saying this License applies to the Document are reproduced in all -copies, and that you add no other conditions whatsoever to those of this -License. You may not use technical measures to obstruct or control the reading -or further copying of the copies you make or distribute. However, you may accept -compensation in exchange for copies. If you distribute a large enough number of -copies you must also follow the conditions in section 3.

-

You may also lend copies, under the same conditions stated above, and you may -publicly display copies.

+ +

You may copy and distribute the Document in any medium, either commercially +or noncommercially, provided that this License, the copyright notices, and +the license notice saying this License applies to the Document are reproduced +in all copies, and that you add no other conditions whatsoever to those of +this License. You may not use technical measures to obstruct or control the +reading or further copying of the copies you make or distribute. However, +you may accept compensation in exchange for copies. If you distribute a large +enough number of copies you must also follow the conditions in section 3. +

+ +

You may also lend copies, under the same conditions stated above, and +you may publicly display copies.

+

3. COPYING IN QUANTITY

-

If you publish printed copies of the Document numbering more than 100, and -the Document's license notice requires Cover Texts, you must enclose the copies -in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover -Texts on the front cover, and Back-Cover Texts on the back cover. Both covers -must also clearly and legibly identify you as the publisher of these copies. The -front cover must present the full title with all words of the title equally -prominent and visible. You may add other material on the covers in addition. -Copying with changes limited to the covers, as long as they preserve the title -of the Document and satisfy these conditions, can be treated as verbatim copying -in other respects.

-

If the required texts for either cover are too voluminous to fit legibly, you -should put the first ones listed (as many as fit reasonably) on the actual + +

If you publish printed copies of the Document numbering more than 100, +and the Document's license notice requires Cover Texts, you must enclose +the copies in covers that carry, clearly and legibly, all these Cover Texts: +Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. +Both covers must also clearly and legibly identify you as the publisher of +these copies. The front cover must present the full title with all words +of the title equally prominent and visible. You may add other material on +the covers in addition. Copying with changes limited to the covers, as long +as they preserve the title of the Document and satisfy these conditions, +can be treated as verbatim copying in other respects.

+ +

If the required texts for either cover are too voluminous to fit legibly, +you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

-

If you publish or distribute Opaque copies of the Document numbering more -than 100, you must either include a machine-readable Transparent copy along with -each Opaque copy, or state in or with each Opaque copy a publicly-accessible -computer-network location containing a complete Transparent copy of the -Document, free of added material, which the general network-using public has -access to download anonymously at no charge using public-standard network -protocols. If you use the latter option, you must take reasonably prudent steps, -when you begin distribution of Opaque copies in quantity, to ensure that this -Transparent copy will remain thus accessible at the stated location until at -least one year after the last time you distribute an Opaque copy (directly or -through your agents or retailers) of that edition to the public.

-

It is requested, but not required, that you contact the authors of the -Document well before redistributing any large number of copies, to give them a -chance to provide you with an updated version of the Document.

+ +

If you publish or distribute Opaque copies of the Document numbering more +than 100, you must either include a machine-readable Transparent copy along +with each Opaque copy, or state in or with each Opaque copy a publicly-accessible +computer-network location containing a complete Transparent copy of the Document, +free of added material, which the general network-using public has access +to download anonymously at no charge using public-standard network protocols. +If you use the latter option, you must take reasonably prudent steps, when +you begin distribution of Opaque copies in quantity, to ensure that this Transparent +copy will remain thus accessible at the stated location until at least one +year after the last time you distribute an Opaque copy (directly or through +your agents or retailers) of that edition to the public.

+ +

It is requested, but not required, that you contact the authors of the +Document well before redistributing any large number of copies, to give them +a chance to provide you with an updated version of the Document.

+

4. MODIFICATIONS

-

You may copy and distribute a Modified Version of the Document under the -conditions of sections 2 and 3 above, provided that you release the Modified -Version under precisely this License, with the Modified Version filling the role -of the Document, thus licensing distribution and modification of the Modified -Version to whoever possesses a copy of it. In addition, you must do these things -in the Modified Version:

-

 

+ +

You may copy and distribute a Modified Version of the Document under the +conditions of sections 2 and 3 above, provided that you release the Modified +Version under precisely this License, with the Modified Version filling the +role of the Document, thus licensing distribution and modification of the +Modified Version to whoever possesses a copy of it. In addition, you must +do these things in the Modified Version:

+ +

 

+
    -
  • A. Use in the Title Page (and on the covers, if any) a - title distinct from that of the Document, and from those of previous versions - (which should, if there were any, be listed in the History section of the - Document). You may use the same title as a previous version if the original - publisher of that version gives permission.
    • -
  • B. List on the Title Page, as authors, one or more - persons or entities responsible for authorship of the modifications in the - Modified Version, together with at least five of the principal authors of the - Document (all of its principal authors, if it has less than five).
    • -
  • C. State on the Title page the name of the publisher of - the Modified Version, as the publisher.
    • -
  • D. Preserve all the copyright notices of the Document. +
  • A. Use in the Title Page (and on the covers, if any) +a title distinct from that of the Document, and from those of previous +versions (which should, if there were any, be listed in the History section +of the Document). You may use the same title as a previous version if the +original publisher of that version gives permission.
    • +
  • B. List on the Title Page, as authors, one or more + persons or entities responsible for authorship of the modifications in +the Modified Version, together with at least five of the principal authors +of the Document (all of its principal authors, if it has less than five).
    • -
  • E. Add an appropriate copyright notice for your - modifications adjacent to the other copyright notices.
    • -
  • F. Include, immediately after the copyright notices, a - license notice giving the public permission to use the Modified Version under - the terms of this License, in the form shown in the Addendum below.
    • -
  • G. Preserve in that license notice the full lists of - Invariant Sections and required Cover Texts given in the Document's license - notice.
    • -
  • H. Include an unaltered copy of this License.
    • -
  • I. Preserve the section entitled "History", and its - title, and add to it an item stating at least the title, year, new authors, - and publisher of the Modified Version as given on the Title Page. If there is - no section entitled "History" in the Document, create one stating the title, - year, authors, and publisher of the Document as given on its Title Page, then - add an item describing the Modified Version as stated in the previous - sentence.
    • -
  • J. Preserve the network location, if any, given in the - Document for public access to a Transparent copy of the Document, and likewise - the network locations given in the Document for previous versions it was based - on. These may be placed in the "History" section. You may omit a network - location for a work that was published at least four years before the Document - itself, or if the original publisher of the version it refers to gives - permission.
    • -
  • K. In any section entitled "Acknowledgements" or - "Dedications", preserve the section's title, and preserve in the section all - the substance and tone of each of the contributor acknowledgements and/or - dedications given therein.
    • -
  • L. Preserve all the Invariant Sections of the Document, - unaltered in their text and in their titles. Section numbers or the equivalent +
  • C. State on the Title page the name of the publisher +of the Modified Version, as the publisher.
    • +
  • D. Preserve all the copyright notices of the Document. +
    • +
  • E. Add an appropriate copyright notice for your + modifications adjacent to the other copyright notices.
    • +
  • F. Include, immediately after the copyright notices, +a license notice giving the public permission to use the Modified Version +under the terms of this License, in the form shown in the Addendum below. +
    • +
  • G. Preserve in that license notice the full lists +of Invariant Sections and required Cover Texts given in the Document's +license notice.
    • +
  • H. Include an unaltered copy of this License.
    • +
  • I. Preserve the section entitled "History", and its + title, and add to it an item stating at least the title, year, new authors, + and publisher of the Modified Version as given on the Title Page. If there +is no section entitled "History" in the Document, create one stating the +title, year, authors, and publisher of the Document as given on its Title +Page, then add an item describing the Modified Version as stated in the +previous sentence.
    • +
  • J. Preserve the network location, if any, given in +the Document for public access to a Transparent copy of the Document, and +likewise the network locations given in the Document for previous versions +it was based on. These may be placed in the "History" section. You may +omit a network location for a work that was published at least four years +before the Document itself, or if the original publisher of the version +it refers to gives permission.
    • +
  • K. In any section entitled "Acknowledgements" or + "Dedications", preserve the section's title, and preserve in the section +all the substance and tone of each of the contributor acknowledgements +and/or dedications given therein.
    • +
  • L. Preserve all the Invariant Sections of the Document, + unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
    • -
  • M. Delete any section entitled "Endorsements". Such a - section may not be included in the Modified Version.
    • -
  • N. Do not retitle any existing section as "Endorsements" +
  • M. Delete any section entitled "Endorsements". Such +a section may not be included in the Modified Version.
    • +
  • N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.
    • +
-

If the Modified Version includes new front-matter sections or appendices that -qualify as Secondary Sections and contain no material copied from the Document, -you may at your option designate some or all of these sections as invariant. To -do this, add their titles to the list of Invariant Sections in the Modified -Version's license notice. These titles must be distinct from any other section -titles.

-

You may add a section entitled "Endorsements", provided it contains nothing -but endorsements of your Modified Version by various parties--for example, -statements of peer review or that the text has been approved by an organization + +

If the Modified Version includes new front-matter sections or appendices +that qualify as Secondary Sections and contain no material copied from the +Document, you may at your option designate some or all of these sections +as invariant. To do this, add their titles to the list of Invariant Sections +in the Modified Version's license notice. These titles must be distinct from +any other section titles.

+ +

You may add a section entitled "Endorsements", provided it contains nothing +but endorsements of your Modified Version by various parties--for example, +statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

-

You may add a passage of up to five words as a Front-Cover Text, and a -passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover -Texts in the Modified Version. Only one passage of Front-Cover Text and one of -Back-Cover Text may be added by (or through arrangements made by) any one -entity. If the Document already includes a cover text for the same cover, -previously added by you or by arrangement made by the same entity you are acting -on behalf of, you may not add another; but you may replace the old one, on -explicit permission from the previous publisher that added the old one.

-

The author(s) and publisher(s) of the Document do not by this License give -permission to use their names for publicity for or to assert or imply + +

You may add a passage of up to five words as a Front-Cover Text, and a +passage of up to 25 words as a Back-Cover Text, to the end of the list of +Cover Texts in the Modified Version. Only one passage of Front-Cover Text +and one of Back-Cover Text may be added by (or through arrangements made +by) any one entity. If the Document already includes a cover text for the +same cover, previously added by you or by arrangement made by the same entity +you are acting on behalf of, you may not add another; but you may replace +the old one, on explicit permission from the previous publisher that added +the old one.

+ +

The author(s) and publisher(s) of the Document do not by this License +give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

+

5. COMBINING DOCUMENTS

-

You may combine the Document with other documents released under this -License, under the terms defined in section 4 above for modified versions, -provided that you include in the combination all of the Invariant Sections of -all of the original documents, unmodified, and list them all as Invariant -Sections of your combined work in its license notice.

-

The combined work need only contain one copy of this License, and multiple -identical Invariant Sections may be replaced with a single copy. If there are -multiple Invariant Sections with the same name but different contents, make the -title of each such section unique by adding at the end of it, in parentheses, -the name of the original author or publisher of that section if known, or else a -unique number. Make the same adjustment to the section titles in the list of -Invariant Sections in the license notice of the combined work.

-

In the combination, you must combine any sections entitled "History" in the -various original documents, forming one section entitled "History"; likewise -combine any sections entitled "Acknowledgements", and any sections entitled -"Dedications". You must delete all sections entitled "Endorsements."

+ +

You may combine the Document with other documents released under this License, +under the terms defined in section 4 above for modified versions, provided +that you include in the combination all of the Invariant Sections of all +of the original documents, unmodified, and list them all as Invariant Sections +of your combined work in its license notice.

+ +

The combined work need only contain one copy of this License, and multiple +identical Invariant Sections may be replaced with a single copy. If there +are multiple Invariant Sections with the same name but different contents, +make the title of each such section unique by adding at the end of it, in +parentheses, the name of the original author or publisher of that section +if known, or else a unique number. Make the same adjustment to the section +titles in the list of Invariant Sections in the license notice of the combined +work.

+ +

In the combination, you must combine any sections entitled "History" in +the various original documents, forming one section entitled "History"; likewise +combine any sections entitled "Acknowledgements", and any sections entitled +"Dedications". You must delete all sections entitled "Endorsements."

+

6. COLLECTIONS OF DOCUMENTS

-

You may make a collection consisting of the Document and other documents -released under this License, and replace the individual copies of this License -in the various documents with a single copy that is included in the collection, -provided that you follow the rules of this License for verbatim copying of each -of the documents in all other respects.

-

You may extract a single document from such a collection, and distribute it -individually under this License, provided you insert a copy of this License into -the extracted document, and follow this License in all other respects regarding -verbatim copying of that document.

+ +

You may make a collection consisting of the Document and other documents +released under this License, and replace the individual copies of this License +in the various documents with a single copy that is included in the collection, +provided that you follow the rules of this License for verbatim copying of +each of the documents in all other respects.

+ +

You may extract a single document from such a collection, and distribute +it individually under this License, provided you insert a copy of this License +into the extracted document, and follow this License in all other respects +regarding verbatim copying of that document.

+

7. AGGREGATION WITH INDEPENDENT WORKS

-

A compilation of the Document or its derivatives with other separate and -independent documents or works, in or on a volume of a storage or distribution -medium, does not as a whole count as a Modified Version of the Document, -provided no compilation copyright is claimed for the compilation. Such a -compilation is called an "aggregate", and this License does not apply to the -other self-contained works thus compiled with the Document, on account of their -being thus compiled, if they are not themselves derivative works of the -Document.

-

If the Cover Text requirement of section 3 is applicable to these copies of -the Document, then if the Document is less than one quarter of the entire -aggregate, the Document's Cover Texts may be placed on covers that surround only -the Document within the aggregate. Otherwise they must appear on covers around -the whole aggregate.

+ +

A compilation of the Document or its derivatives with other separate and +independent documents or works, in or on a volume of a storage or distribution +medium, does not as a whole count as a Modified Version of the Document, provided +no compilation copyright is claimed for the compilation. Such a compilation +is called an "aggregate", and this License does not apply to the other self-contained +works thus compiled with the Document, on account of their being thus compiled, +if they are not themselves derivative works of the Document.

+ +

If the Cover Text requirement of section 3 is applicable to these copies +of the Document, then if the Document is less than one quarter of the entire +aggregate, the Document's Cover Texts may be placed on covers that surround +only the Document within the aggregate. Otherwise they must appear on covers +around the whole aggregate.

+

8. TRANSLATION

-

Translation is considered a kind of modification, so you may distribute -translations of the Document under the terms of section 4. Replacing Invariant -Sections with translations requires special permission from their copyright -holders, but you may include translations of some or all Invariant Sections in -addition to the original versions of these Invariant Sections. You may include a -translation of this License provided that you also include the original English -version of this License. In case of a disagreement between the translation and -the original English version of this License, the original English version will -prevail.

+ +

Translation is considered a kind of modification, so you may distribute +translations of the Document under the terms of section 4. Replacing Invariant +Sections with translations requires special permission from their copyright +holders, but you may include translations of some or all Invariant Sections +in addition to the original versions of these Invariant Sections. You may +include a translation of this License provided that you also include the +original English version of this License. In case of a disagreement between +the translation and the original English version of this License, the original +English version will prevail.

+

9. TERMINATION

-

You may not copy, modify, sublicense, or distribute the Document except as -expressly provided for under this License. Any other attempt to copy, modify, -sublicense or distribute the Document is void, and will automatically terminate -your rights under this License. However, parties who have received copies, or -rights, from you under this License will not have their licenses terminated so -long as such parties remain in full compliance.

+ +

You may not copy, modify, sublicense, or distribute the Document except +as expressly provided for under this License. Any other attempt to copy, +modify, sublicense or distribute the Document is void, and will automatically +terminate your rights under this License. However, parties who have received +copies, or rights, from you under this License will not have their licenses +terminated so long as such parties remain in full compliance.

+

10. FUTURE REVISIONS OF THIS LICENSE

-

The Free Software Foundation may publish new, revised versions of the GNU -Free Documentation License from time to time. Such new versions will be similar -in spirit to the present version, but may differ in detail to address new -problems or concerns. See http://www.gnu.org/copyleft/.

-

Each version of the License is given a distinguishing version number. If the -Document specifies that a particular numbered version of this License "or any -later version" applies to it, you have the option of following the terms and -conditions either of that specified version or of any later version that has -been published (not as a draft) by the Free Software Foundation. If the Document -does not specify a version number of this License, you may choose any version -ever published (not as a draft) by the Free Software Foundation.

-

 

- + +

The Free Software Foundation may publish new, revised versions of the +GNU Free Documentation License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. See http://www.gnu.org/copyleft/.

+ +

Each version of the License is given a distinguishing version number. +If the Document specifies that a particular numbered version of this License +"or any later version" applies to it, you have the option of following the +terms and conditions either of that specified version or of any later version +that has been published (not as a draft) by the Free Software Foundation. +If the Document does not specify a version number of this License, you may +choose any version ever published (not as a draft) by the Free Software Foundation. +

+ +

 

+
- - \ No newline at end of file + diff --git a/STABLE/documentation/IPIP.htm b/STABLE/documentation/IPIP.htm index 02e4bd63c..28370194a 100644 --- a/STABLE/documentation/IPIP.htm +++ b/STABLE/documentation/IPIP.htm @@ -1,248 +1,249 @@ - + GRE/IPIP Tunnels - + - + - + - - - + + - - - + + + +
+ id="AutoNumber1" bgcolor="#3366ff" height="90"> +

GRE and IPIP Tunnels

-
- -

Warning: GRE and IPIP Tunnels are insecure + +

Warning: GRE and IPIP Tunnels are insecure when used over the internet; use them at your own risk

- -

GRE and IPIP tunneling with Shorewall can be used to bridge two masqueraded + +

GRE and IPIP tunneling with Shorewall can be used to bridge two masqueraded networks.

- -

The simple scripts described in the Linux -Advanced Routing and Shaping HOWTO work fine with Shorewall. Shorewall -also includes a tunnel script for automating tunnel configuration. If you -have installed the RPM, the tunnel script may be found in the Shorewall documentation + +

The simple scripts described in the Linux +Advanced Routing and Shaping HOWTO work fine with Shorewall. Shorewall +also includes a tunnel script for automating tunnel configuration. If you +have installed the RPM, the tunnel script may be found in the Shorewall documentation directory (usually /usr/share/doc/shorewall-<version>/).

- +

Bridging two Masqueraded Networks

- +

Suppose that we have the following situation:

- +

-

- -

We want systems in the 192.168.1.0/24 subnetwork to be able -to communicate with the systems in the 10.0.0.0/8 network. This is accomplished -through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy +

+ +

We want systems in the 192.168.1.0/24 subnetwork to be able +to communicate with the systems in the 10.0.0.0/8 network. This is accomplished +through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy file and the /etc/shorewall/tunnel script that is included with Shorewall.

- -

The 'tunnel' script is not installed in /etc/shorewall by -default -- If you install using the tarball, the script is included in the -tarball; if you install using the RPM, the file is in your Shorewall documentation + +

The 'tunnel' script is not installed in /etc/shorewall by +default -- If you install using the tarball, the script is included in the +tarball; if you install using the RPM, the file is in your Shorewall documentation directory (normally /usr/share/doc/shorewall-<version>).

- -

In the /etc/shorewall/tunnel script, set the 'tunnel_type' + +

In the /etc/shorewall/tunnel script, set the 'tunnel_type' parameter to the type of tunnel that you want to create.

- +

Example:

- -
+ +

tunnel_type=gre

-
- -

On each firewall, you will need to declare a zone to represent - the remote subnet. We'll assume that this zone is called 'vpn' and declare +

+ +

On each firewall, you will need to declare a zone to represent + the remote subnet. We'll assume that this zone is called 'vpn' and declare it in /etc/shorewall/zones on both systems as follows.

- -
+ +
- + + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
+
+ +

On system A, the 10.0.0.0/8 will comprise the vpn zone. +In /etc/shorewall/interfaces:

+ +
+ + + + + + + + - - - - - - - - - - - + + + + + + +
ZONEINTERFACEBROADCASTOPTIONS
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
vpntosysb10.255.255.255 
- -

On system A, the 10.0.0.0/8 will comprise the vpn -zone. In /etc/shorewall/interfaces:

- -
- - - - - - - - - - - - - - - - -
ZONEINTERFACEBROADCASTOPTIONS
vpntosysb10.255.255.255 
-
- +

In /etc/shorewall/tunnels on system A, we need the following:

- -
+ +
- + + + + + + + - - - - - - - - - - - - - + + + + + + +
TYPEZONEGATEWAYGATEWAY ZONE
TYPEZONEGATEWAYGATEWAY ZONE
ipipnet134.28.54.2 
ipipnet134.28.54.2 
-
- -

This entry in /etc/shorewall/tunnels, opens the firewall so that the IP +

+ +

This entry in /etc/shorewall/tunnels, opens the firewall so that the IP encapsulation protocol (4) will be accepted to/from the remote gateway.

- +

In the tunnel script on system A:

- -
+ +

tunnel=tosysb
- myrealip=206.161.148.9 (for GRE tunnel only)
- myip=192.168.1.1
- hisip=10.0.0.1
- gateway=134.28.54.2
- subnet=10.0.0.0/8

-
- -

Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn + myrealip=206.161.148.9 (for GRE tunnel only)
+ myip=192.168.1.1
+ hisip=10.0.0.1
+ gateway=134.28.54.2
+ subnet=10.0.0.0/8

+
+ +

Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn zone. In /etc/shorewall/interfaces:

- -
+ +
- + + + + + + + - - - - - - - - - - - - - + + + + + + +
ZONEINTERFACEBROADCASTOPTIONS
ZONEINTERFACEBROADCASTOPTIONS
vpntosysa192.168.1.255 
vpntosysa192.168.1.255 
-
- +
+

In /etc/shorewall/tunnels on system B, we have:

- -
+ +
- + + + + + + + - - - - - - - - - - - - - + + + + + + +
TYPEZONEGATEWAYGATEWAY ZONE
TYPEZONEGATEWAYGATEWAY ZONE
ipipnet206.191.148.9 
ipipnet206.191.148.9 
-
- +
+

And in the tunnel script on system B:

- -
+ +

tunnel=tosysa
- myrealip=134.28.54.2 (for GRE tunnel only)
- myip=10.0.0.1
- hisip=192.168.1.1
- gateway=206.191.148.9
- subnet=192.168.1.0/24

-
- -

You can rename the modified tunnel scripts if you like; be sure that they + myrealip=134.28.54.2 (for GRE tunnel only)
+ myip=10.0.0.1
+ hisip=192.168.1.1
+ gateway=206.191.148.9
+ subnet=192.168.1.0/24

+
+ +

You can rename the modified tunnel scripts if you like; be sure that they are secured so that root can execute them.

- -

You will need to allow traffic between the "vpn" zone and - the "loc" zone on both systems -- if you simply want to admit all -traffic in both directions, you can use the policy file:

- -
+ +

You will need to allow traffic between the "vpn" zone and + the "loc" zone on both systems -- if you simply want to admit all traffic + in both directions, you can use the policy file:

+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
-
- -

On both systems, restart Shorewall and run the modified tunnel script -with the "start" argument on each system. The systems in the two masqueraded -subnetworks can now talk to each other

- -

Updated 2/22/2003 - Tom Eastep +

+ +

On both systems, restart Shorewall and run the modified tunnel script with +the "start" argument on each system. The systems in the two masqueraded subnetworks +can now talk to each other

+ +

Updated 2/22/2003 - Tom Eastep

- +

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

-
+
+
diff --git a/STABLE/documentation/IPSEC.htm b/STABLE/documentation/IPSEC.htm index 7a0afd53a..d7708a0f3 100644 --- a/STABLE/documentation/IPSEC.htm +++ b/STABLE/documentation/IPSEC.htm @@ -1,767 +1,771 @@ - + Shorewall IPSec Tunneling - + - + - + - - - + + - - - + + + +
+ id="AutoNumber1" bgcolor="#3366ff" height="90"> +

IPSEC Tunnels

-
- +

Configuring FreeS/Wan

- There is an excellent guide to configuring IPSEC tunnels at http://www.geocities.com/jixen66/ - . I highly recommend that you consult that site for information about configuring - FreeS/Wan.  -

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. 

- -

You might be able to work around this problem using the following + There is an excellent guide to configuring IPSEC tunnels at http://www.geocities.com/jixen66/ + . I highly recommend that you consult that site for information about configuring + FreeS/Wan.  +

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. 

+ +

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

- +

In /etc/shorewall/init, include:

- +

     qt service ipsec stop

- +

In /etc/shorewall/start, include:

- +

    qt service ipsec start

- +

IPSec Gateway on the Firewall System

- +

Suppose that we have the following sutuation:

- +

-

- -

We want systems in the 192.168.1.0/24 sub-network to be able +

+ +

We want systems in the 192.168.1.0/24 sub-network to be able to communicate with systems in the 10.0.0.0/8 network.

- +

To make this work, we need to do two things:

- -

a) Open the firewall so that the IPSEC tunnel can be established + +

a) Open the firewall so that the IPSEC tunnel can be established (allow the ESP and AH protocols and UDP Port 500).

- +

b) Allow traffic through the tunnel.

- -

Opening the firewall for the IPSEC tunnel is accomplished + +

Opening the firewall for the IPSEC tunnel is accomplished by adding an entry to the /etc/shorewall/tunnels file.

- +

In /etc/shorewall/tunnels on system A, we need the following 

- -
+ +
- - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet134.28.54.2 
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet134.28.54.2 
-
- +
+

In /etc/shorewall/tunnels on system B, we would have:

- -
+ +
- - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet206.161.148.9 
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet206.161.148.9 
-
- -

Note: If either of the endpoints is behind a NAT gateway - then the tunnels file entry on the other endpoint should -specify a tunnel type of ipsecnat rather than ipsec and the -GATEWAY address should specify the external address of the NAT gateway.
-

- -

You need to define a zone for the remote subnet or include - it in your local zone. In this example, we'll assume that you have +

+ +

Note: If either of the endpoints is behind a NAT gateway + then the tunnels file entry on the other endpoint should specify + a tunnel type of ipsecnat rather than ipsec and the GATEWAY + address should specify the external address of the NAT gateway.
+

+ +

You need to define a zone for the remote subnet or include + it in your local zone. In this example, we'll assume that you have created a zone called "vpn" to represent the remote subnet.

- -
+ +
- - - - - - - - - - - - - + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
-
- -

At both systems, ipsec0 would be included in /etc/shorewall/interfaces +

+ +

At both systems, ipsec0 would be included in /etc/shorewall/interfaces as a "vpn" interface:

- -
+ +
- - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
vpnipsec0  
ZONE INTERFACE BROADCAST OPTIONS
vpnipsec0  
-
- -

You will need to allow traffic between the "vpn" zone and - the "loc" zone -- if you simply want to admit all traffic in both +

+ +

You will need to allow traffic between the "vpn" zone and + the "loc" zone -- if you simply want to admit all traffic in both directions, you can use the policy file:

- -
+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
-
- -

Once you have these entries in place, restart Shorewall (type -shorewall restart); you are now ready to configure the tunnel in + +

Once you have these entries in place, restart Shorewall +(type shorewall restart); you are now ready to configure the tunnel in FreeS/WAN .

- +

VPN Hub

- Shorewall can be used in a VPN Hub environment where multiple remote networks -are connected to a gateway running Shorewall. This environment is shown in -this diatram.
- + Shorewall can be used in a VPN Hub environment where multiple remote networks + are connected to a gateway running Shorewall. This environment is shown +in this diatram.
+
(Three networks linked with IPSEC) -
-
- -

We want systems in the 192.168.1.0/24 sub-network to be able - to communicate with systems in the 10.0.0.0/16 and 10.1.0.0/16 networks -and we want the 10.0.0.0/16 and 10.1.0.0/16 networks to be able to communicate.

- +
+
+ +

We want systems in the 192.168.1.0/24 sub-network to be able + to communicate with systems in the 10.0.0.0/16 and 10.1.0.0/16 networks + and we want the 10.0.0.0/16 and 10.1.0.0/16 networks to be able to communicate.

+

To make this work, we need to do several things:

- -

a) Open the firewall so that two IPSEC tunnels can be established + +

a) Open the firewall so that two IPSEC tunnels can be established (allow the ESP and AH protocols and UDP Port 500).

- -

b) Allow traffic through the tunnels two/from the local zone -(192.168.1.0/24).
-

- -

c) Deny traffic through the tunnels between the two remote -networks.
-

- -

Opening the firewall for the IPSEC tunnels is accomplished + +

b) Allow traffic through the tunnels two/from the local zone + (192.168.1.0/24).
+

+ +

c) Deny traffic through the tunnels between the two remote + networks.
+

+ +

Opening the firewall for the IPSEC tunnels is accomplished by adding two entries to the /etc/shorewall/tunnels file.

- +

In /etc/shorewall/tunnels on system A, we need the following 

- -
+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsec
- 		net134.28.54.2 
ipsec
- 		net
- 		130.152.100.14
-
-
TYPE ZONE GATEWAY GATEWAY ZONE
ipsec
+ 		net134.28.54.2 
ipsec
+ 		net
+ 		130.152.100.14
+
+
-
- +
+

In /etc/shorewall/tunnels on systems B and C, we would have:

- -
+ +
- - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet206.161.148.9 
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet206.161.148.9 
-
- +
+

- -

Note: If either of the endpoints is behind a NAT gateway - then the tunnels file entry on the other endpoint should -specify a tunnel type of ipsecnat rather than ipsec
- and the GATEWAY address should specify the external address of the -NAT gateway.
-

- -

On each system, we will create a zone to represent the remote -networks. On System A:
-

- -
- - - - - - - - - - - - - - - - - - - -
ZONEDISPLAYCOMMENTS
vpn1VPN1Remote Subnet on system B
vpn2
- 		VPN2
- 		Remote Subnet on system C
-
-
- -

On systems B and C:
-

- -
- - - - - - - - - - - - - - -
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet on system A
-
- -

At system A, ipsec0 represents two zones so we have the following -in /etc/shorewall/interfaces:

- -
- - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
-
- 		ipsec0 
-
-
- -

The /etc/shorewall/hosts file on system A defines the two -VPN zones:
-

- -
- - - - - - - - - - - - - - - - - - - -
ZONE HOSTS
- 		OPTIONS
vpn1
- 		ipsec0:10.0.0.0/16
-
vpn2
- 		ipsec0:10.1.0.0/16
-
-
-
- -

At systems B and C, ipsec0 represents a single zone so we -have the following in /etc/shorewall/interfaces:

- -
- - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
vpn
- 		ipsec0 
-
-
-
-

On systems A, you will need to allow traffic between the "vpn1" -zone and the "loc" zone as well as between "vpn2" and the "loc" zone --- if you simply want to admit all traffic in both directions, you -can use the following policy file entries on all three gateways:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

Note: If either of the endpoints is behind a NAT gateway + then the tunnels file entry on the other endpoint should specify + a tunnel type of ipsecnat rather than ipsec
+ and the GATEWAY address should specify the external address of the + NAT gateway.
+

- -
SOURCEDESTPOLICYLOG LEVEL
locvpn1ACCEPT 
vpn1locACCEPT 
loc
- 		vpn2
- 		ACCEPT
-
-
vpn2
- 		loc
- 		ACCEPT
-
-
-
-

On systems B and C, you will need to allow traffic between -the "vpn" zone and the "loc" zone -- if you simply want to admit all -traffic in both directions, you can use the following policy file entries -on all three gateways:

- -
- - - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
-
- -

Once you have the Shorewall entries added, restart Shorewall -on each gateway (type shorewall restart); you are now ready to configure -the tunnels in FreeS/WAN - .

- Note that to allow traffic between the networks attached to systems B and -C, it is necessary to simply add two additional entries to the /etc/shorewall/policy -file on system A.
-
- - - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG LEVEL
vpn1
- 		vpn2ACCEPT 
vpn2vpn1
- 		ACCEPT 
-
-
- -

Mobile System -(Road Warrior)

- -

Suppose that you have a laptop system (B) that you take with you when you -travel and you want to be able to establish a secure connection back to your -local network.

- -

- -

- -

You need to define a zone for the laptop or include it in - your local zone. In this example, we'll assume that you have created - a zone called "vpn" to represent the remote host.

- -
- - - - - - - - - - - - - - -
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
-
- -

In this instance, the mobile system (B) has IP address 134.28.54.2 - but that cannot be determined in advance. In the /etc/shorewall/tunnels -file on system A, the following entry should be made:

- -
- - - - - - - - - - - - - - - - -
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet0.0.0.0/0vpn
-
- -

Note that the GATEWAY ZONE column contains the name of the zone corresponding - to peer subnetworks. This indicates that the gateway system itself comprises - the peer subnetwork; in other words, the remote gateway is a standalone -system.

- -

You will need to configure /etc/shorewall/interfaces and establish - your "through the tunnel" policy as shown under the first example above.
+

On each system, we will create a zone to represent the remote + networks. On System A:

- -

Dynamic RoadWarrior Zones

- Beginning with Shorewall release 1.3.10, you can define multiple VPN -zones and add and delete remote endpoints dynamically using /sbin/shorewall. -In /etc/shorewall/zones:
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - + +
+
ZONE
- 		DISPLAY
- 		COMMENTS
-
vpn1
- 		VPN-1
- 		First VPN Zone
-
vpn2
- 		VPN-2
- 		Second VPN Zone
-
vpn3
- 		VPN-3
- 		Third VPN Zone
-
+ + + + + + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpn1VPN1Remote Subnet on system B
vpn2
+ 		VPN2
+ 		Remote Subnet on system C
+
-
-
- In /etc/shorewall/tunnels:
- -
+
+ +

On systems B and C:
+

+ +
+ + + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet on system A
+
+ +

At system A, ipsec0 represents two zones so we have the following + in /etc/shorewall/interfaces:

+ +
+ + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
-
+ 		ipsec0 
+
+
+ +

The /etc/shorewall/hosts file on system A defines the two + VPN zones:
+

+ +
+ + + + + + + + + + + + + + + + + + + +
ZONE HOSTS
+ 		OPTIONS
vpn1
+ 		ipsec0:10.0.0.0/16
+
vpn2
+ 		ipsec0:10.1.0.0/16
+
+
+
+ +

At systems B and C, ipsec0 represents a single zone so we + have the following in /etc/shorewall/interfaces:

+ +
+ + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
vpn
+ 		ipsec0 
+
+
+
+ +

On systems A, you will need to allow traffic between the +"vpn1" zone and the "loc" zone as well as between "vpn2" and the +"loc" zone -- if you simply want to admit all traffic in both directions, +you can use the following policy file entries on all three gateways:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
locvpn1ACCEPT 
vpn1locACCEPT 
loc
+ 		vpn2
+ 		ACCEPT
+
+
vpn2
+ 		loc
+ 		ACCEPT
+
+
+
+ +

On systems B and C, you will need to allow traffic between + the "vpn" zone and the "loc" zone -- if you simply want to admit +all traffic in both directions, you can use the following policy file +entries on all three gateways:

+ +
+ + + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
+
+ +

Once you have the Shorewall entries added, restart Shorewall + on each gateway (type shorewall restart); you are now ready to configure + the tunnels in FreeS/WAN + .

+ Note that to allow traffic between the networks attached to systems B and + C, it is necessary to simply add two additional entries to the /etc/shorewall/policy + file on system A.
+ +
+ + + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
vpn1
+ 		vpn2ACCEPT 
vpn2vpn1
+ 		ACCEPT 
+
+
+ +

Mobile System + (Road Warrior)

+ +

Suppose that you have a laptop system (B) that you take with you when +you travel and you want to be able to establish a secure connection back +to your local network.

+ +

+ +

+ +

You need to define a zone for the laptop or include it in + your local zone. In this example, we'll assume that you have created + a zone called "vpn" to represent the remote host.

+ +
+ + + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
+
+ +

In this instance, the mobile system (B) has IP address 134.28.54.2 + but that cannot be determined in advance. In the /etc/shorewall/tunnels +file on system A, the following entry should be made:

+ +
+ + + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet0.0.0.0/0vpn
+
+ +

Note that the GATEWAY ZONE column contains the name of the zone corresponding + to peer subnetworks. This indicates that the gateway system itself comprises + the peer subnetwork; in other words, the remote gateway is a standalone +system.

+ +

You will need to configure /etc/shorewall/interfaces and establish + your "through the tunnel" policy as shown under the first example above.
+

+ +

Dynamic RoadWarrior Zones

+ Beginning with Shorewall release 1.3.10, you can define multiple VPN + zones and add and delete remote endpoints dynamically using /sbin/shorewall. + In /etc/shorewall/zones:
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + +
ZONE
+ 		DISPLAY
+ 		COMMENTS
+
vpn1
+ 		VPN-1
+ 		First VPN Zone
+
vpn2
+ 		VPN-2
+ 		Second VPN Zone
+
vpn3
+ 		VPN-3
+ 		Third VPN Zone
+
+
+
+ In /etc/shorewall/tunnels:
+ +
- - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
TYPE
- 		ZONE
- 		GATEWAY
- 		GATEWAY ZONE
-
ipsec
- 		net
- 		0.0.0.0/0
- 		vpn1,vpn2,vpn3
-
TYPE
+ 		ZONE
+ 		GATEWAY
+ 		GATEWAY ZONE
+
ipsec
+ 		net
+ 		0.0.0.0/0
+ 		vpn1,vpn2,vpn3
+
-
-
- When Shorewall is started, the zones vpn[1-3] will all be empty and -Shorewall will issue warnings to that effect. These warnings may be safely -ignored. FreeS/Wan may now be configured to have three different Road Warrior -connections with the choice of connection being based on X-509 certificates -or some other means. Each of these connectioins will utilize a different -updown script that adds the remote station to the appropriate zone when the -connection comes up and that deletes the remote station when the connection -comes down. For example, when 134.28.54.2 connects for the vpn2 zone the +
+ + When Shorewall is started, the zones vpn[1-3] will all be empty and +Shorewall will issue warnings to that effect. These warnings may be safely +ignored. FreeS/Wan may now be configured to have three different Road Warrior +connections with the choice of connection being based on X-509 certificates +or some other means. Each of these connectioins will utilize a different +updown script that adds the remote station to the appropriate zone when the +connection comes up and that deletes the remote station when the connection +comes down. For example, when 134.28.54.2 connects for the vpn2 zone the 'up' part of the script will issue the command":
-
- +
+
/sbin/shorewall add ipsec0:134.28.54.2 vpn2
-
- and the 'down' part will:
- + + and the 'down' part will:
+
/sbin/shorewall delete ipsec0:134.28.54.2 vpn
-
-
- +
+ +

Limitations of Dynamic Zones

- If you include a dynamic zone in the exclude list of a DNAT rule, the dynamically-added - hosts are not excluded from the rule.
-
- Example with dyn=dynamic zone:
-
- -
+ If you include a dynamic zone in the exclude list of a DNAT rule, the +dynamically-added hosts are not excluded from the rule.
+
+ Example with dyn=dynamic zone:
+
+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTION
- 		SOURCE
- 		DESTINATION
- 		PROTOCOL
- 		PORT(S)
- 		CLIENT
- PORT(S)
- 		ORIGINAL
- DESTINATION
-
DNAT
- 		z:dyn
- 		loc:192.168.1.3
- 		tcp
- 		80
-
-
-
ACTION
+ 		SOURCE
+ 		DESTINATION
+ 		PROTOCOL
+ 		PORT(S)
+ 		CLIENT
+ PORT(S)
+ 		ORIGINAL
+ DESTINATION
+
DNAT
+ 		z:dyn
+ 		loc:192.168.1.3
+ 		tcp
+ 		80
+
+
+
-
- Dynamic changes to the zone dyn will have no effect on the above -rule. +
+ Dynamic changes to the zone dyn will have no effect on the above + rule.

Last updated 6/10//2003 - Tom Eastep

- +

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

+

+

diff --git a/STABLE/documentation/Install.htm b/STABLE/documentation/Install.htm index 38a25882d..7c69068e7 100644 --- a/STABLE/documentation/Install.htm +++ b/STABLE/documentation/Install.htm @@ -1,220 +1,221 @@ - + Shorewall Installation - + - + - + - - - + + - - - + + + +
-

Shorewall Installation and + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

+

Shorewall Installation and Upgrade

-
- +

Before upgrading, be sure to review the Upgrade Issues
-

- -
Before attempting installation, I strongly urge you to -read and print a copy of the Shorewall QuickStart Guide - for the configuration that most closely matches your own.
-
- +

+ +
Before attempting installation, I strongly urge you +to read and print a copy of the Shorewall QuickStart Guide + for the configuration that most closely matches your own.
+
+

Install using RPM
- Install using tarball
- Install the .lrp
- Upgrade using RPM
- Upgrade using tarball
- Upgrade the .lrp
- Configuring Shorewall
- Uninstall/Fallback

- + Install using tarball
+ Install the .lrp
+ Upgrade using RPM
+ Upgrade using tarball
+ Upgrade the .lrp
+ Configuring Shorewall
+ Uninstall/Fallback

+

To install Shorewall using the RPM:

- -

If you have RedHat 7.2 and are running iptables version 1.2.3 (at a - shell prompt, type "/sbin/iptables --version"), you must upgrade to -version 1.2.4 either from the RedHat update - site or from the Shorewall Errata page -before attempting to start Shorewall.

- + +

If you have RedHat 7.2 and are running iptables version 1.2.3 (at a + shell prompt, type "/sbin/iptables --version"), you must upgrade to version + 1.2.4 either from the RedHat update + site or from the Shorewall Errata page before + attempting to start Shorewall.

+
    -
  • Install the RPM (rpm -ivh <shorewall rpm>).
    -
    - Note1: Some SuSE  users have encountered a problem whereby - rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel - is installed. If this happens, simply use the --nodeps option to rpm +
  • Install the RPM (rpm -ivh <shorewall rpm>).
    +
    + Note1: Some SuSE  users have encountered a problem whereby + rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel + is installed. If this happens, simply use the --nodeps option to rpm (rpm -ivh --nodeps <shorewall rpm>.
    -
    - Note2: Beginning with Shorewall 1.4.0, Shorewall is dependent - on the iproute package. Unfortunately, some distributions call this package - iproute2 which will cause the installation of Shorewall to fail with the - diagnostic:
    -
    -      error: failed dependencies:iproute is needed by shorewall-1.4.x-1
    -
    - This may be worked around by using the --nodeps option of rpm (rpm -ivh - --nodeps <shorewall rpm>).
    -
    -
    • -
  • Edit the configuration files -to match your configuration. WARNING - YOU CAN - NOT SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. -SOME CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU -ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR SYSTEM WILL -NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE A "shorewall -clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.
    • -
  • Start the firewall by typing "shorewall start"
    • - + Note2: Beginning with Shorewall 1.4.0, Shorewall is dependent + on the iproute package. Unfortunately, some distributions call this package + iproute2 which will cause the installation of Shorewall to fail with the + diagnostic:
    +
    +      error: failed dependencies:iproute is needed by shorewall-1.4.x-1 +
    +
    + This may be worked around by using the --nodeps option of rpm (rpm -ivh + --nodeps <shorewall rpm>).
    +
    + +
  • Edit the configuration files + to match your configuration. WARNING - YOU CAN + NOT SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" +COMMAND. SOME CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START. +IF YOU ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR +SYSTEM WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE +A "shorewall clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.
    • +
  • Start the firewall by typing "shorewall start"
    • +
- -

To install Shorewall using the tarball + +

To install Shorewall using the tarball and install script:

- +
    -
  • unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
    • -
  • cd to the shorewall directory (the version is encoded in +
  • unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
    • +
  • cd to the shorewall directory (the version is encoded in the directory name as in "shorewall-1.1.10").
    • -
  • If you are using If you are using Caldera, RedHat, Mandrake, Corel, Slackware or Debian then type "./install.sh"
    • -
  • If you are using SuSe then - type "./install.sh /etc/init.d"
    • -
  • If your distribution has directory /etc/rc.d/init.d +
  • If you are using SuSe +then type "./install.sh /etc/init.d"
    • +
  • If your distribution has directory /etc/rc.d/init.d or /etc/init.d then type "./install.sh"
    • -
  • For other distributions, determine where your - distribution installs init scripts and type "./install.sh -<init script directory>
    • -
  • Edit the configuration files -to match your configuration.
    • -
  • Start the firewall by typing "shorewall start"
    • -
  • If the install script was unable to configure Shorewall to - be started automatically at boot, see For other distributions, determine where your + distribution installs init scripts and type "./install.sh + <init script directory>
    • +
  • Edit the configuration files + to match your configuration.
    • +
  • Start the firewall by typing "shorewall start"
    • +
  • If the install script was unable to configure Shorewall +to be started automatically at boot, see these instructions.
    • - +
- -

To install my version of Shorewall on a fresh Bering - disk, simply replace the "shorwall.lrp" file on the image with the file - that you downloaded. See the two-interface QuickStart - Guide for information about further steps required.

- -

If you already have the Shorewall RPM installed + +

To install my version of Shorewall on a fresh Bering + disk, simply replace the "shorwall.lrp" file on the image with the file + that you downloaded. See the two-interface +QuickStart Guide for information about further steps required.

+ +

If you already have the Shorewall RPM installed and are upgrading to a new version:

- -

If you are upgrading from a 1.2 version of Shorewall to a 1.4 version -or and you have entries in the /etc/shorewall/hosts file then please check - your /etc/shorewall/interfaces file to be sure that it contains an entry - for each interface mentioned in the hosts file. Also, there are certain - 1.2 rule forms that are no longer supported under 1.4 (you must use the - new 1.4 syntax). See the upgrade issues for - details.

- + +

If you are upgrading from a 1.2 version of Shorewall to a 1.4 version or +and you have entries in the /etc/shorewall/hosts file then please check +your /etc/shorewall/interfaces file to be sure that it contains an entry + for each interface mentioned in the hosts file. Also, there are certain + 1.2 rule forms that are no longer supported under 1.4 (you must use the + new 1.4 syntax). See the upgrade issues for + details.

+
    -
  • Upgrade the RPM (rpm -Uvh <shorewall rpm file>) Note: - If you are installing version 1.2.0 and have one of the 1.2.0 - Beta RPMs installed, you must use the "--oldpackage" option to rpm -(e.g., "rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm"). - -

    Note1: Some SuSE users have encountered a problem whereby - rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel - is installed. If this happens, simply use the --nodeps option to rpm - (rpm -Uvh --nodeps <shorewall rpm>).
    +

  • Upgrade the RPM (rpm -Uvh <shorewall rpm file>) Note: + If you are installing version 1.2.0 and have one of the 1.2.0 + Beta RPMs installed, you must use the "--oldpackage" option to rpm +(e.g., "rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm"). + +

    Note1: Some SuSE users have encountered a problem whereby + rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel + is installed. If this happens, simply use the --nodeps option to rpm + (rpm -Uvh --nodeps <shorewall rpm>).
    +
    + Note3: Beginning with Shorewall 1.4.0, Shorewall is dependent + on the iproute package. Unfortunately, some distributions call this package + iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:

    - Note3: Beginning with Shorewall 1.4.0, Shorewall is dependent - on the iproute package. Unfortunately, some distributions call this package - iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:
    -
    -      error: failed dependencies:iproute is needed by shorewall-1.4.0-1 +      error: failed dependencies:iproute is needed by shorewall-1.4.0-1
    -
    - This may be worked around by using the --nodeps option of rpm (rpm -Uvh - --nodeps <shorewall rpm>). 

    -
    • -
  • See if there are any incompatibilities between your configuration - and the new Shorewall version (type "shorewall check") and correct -as necessary.
    • -
  • Restart the firewall (shorewall restart).
    • - +
    + This may be worked around by using the --nodeps option of rpm (rpm +-Uvh --nodeps <shorewall rpm>). 

    + +
  • See if there are any incompatibilities between your configuration + and the new Shorewall version (type "shorewall check") and correct as + necessary.
    • +
  • Restart the firewall (shorewall restart).
    • +
- -

If you already have Shorewall installed and -are upgrading to a new version using the tarball:

- -

If you are upgrading from a 1.2 version of Shorewall to a 1.4 version and -you have entries in the /etc/shorewall/hosts file then please check your - /etc/shorewall/interfaces file to be sure that it contains an entry for -each interface mentioned in the hosts file.  Also, there are certain 1.2 -rule forms that are no longer supported under 1.4 (you must use the new -1.4 syntax). See the upgrade issues for -details.

- + +

If you already have Shorewall installed +and are upgrading to a new version using the tarball:

+ +

If you are upgrading from a 1.2 version of Shorewall to a 1.4 version +and you have entries in the /etc/shorewall/hosts file then please check +your /etc/shorewall/interfaces file to be sure that it contains an entry +for each interface mentioned in the hosts file.  Also, there are certain +1.2 rule forms that are no longer supported under 1.4 (you must use the +new 1.4 syntax). See the upgrade issues +for details.

+
    -
  • unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
    • -
  • cd to the shorewall directory (the version is encoded in +
  • unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
    • +
  • cd to the shorewall directory (the version is encoded in the directory name as in "shorewall-3.0.1").
    • -
  • If you are using If you are using Caldera, RedHat, Mandrake, Corel, Slackware or Debian then type "./install.sh"
    • -
  • If you are using SuSe then - type "./install.sh /etc/init.d"
    • -
  • If your distribution has directory /etc/rc.d/init.d +
  • If you are using SuSe +then type "./install.sh /etc/init.d"
    • +
  • If your distribution has directory /etc/rc.d/init.d or /etc/init.d then type "./install.sh"
    • -
  • For other distributions, determine where your - distribution installs init scripts and type "./install.sh -<init script directory>
    • -
  • See if there are any incompatibilities between your configuration - and the new Shorewall version (type "shorewall check") and correct -as necessary.
    • -
  • Restart the firewall by typing "shorewall restart"
    • - +
  • For other distributions, determine where your + distribution installs init scripts and type "./install.sh + <init script directory>
    • +
  • See if there are any incompatibilities between your configuration + and the new Shorewall version (type "shorewall check") and correct as + necessary.
    • +
  • Restart the firewall by typing "shorewall restart"
    • +
- If you already have a running Bering - installation and wish to upgrade to a later version of Shorewall:
-
-     UNDER CONSTRUCTION...
- + If you already have a running +Bering installation and wish to upgrade to a later version of Shorewall:
+
+     UNDER CONSTRUCTION...
+

Configuring Shorewall

- -

You will need to edit some or all of the configuration files to match -your setup. In most cases, the Shorewall + +

You will need to edit some or all of the configuration files to match your + setup. In most cases, the Shorewall QuickStart Guides contain all of the information you need.

- +
    - +
- -

Updated 4/8/2003 - Tom Eastep + +

Updated 4/8/2003 - Tom Eastep

- +

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

+

+

diff --git a/STABLE/documentation/MAC_Validation.html b/STABLE/documentation/MAC_Validation.html index 7c47fade6..4242b0e5a 100644 --- a/STABLE/documentation/MAC_Validation.html +++ b/STABLE/documentation/MAC_Validation.html @@ -2,116 +2,120 @@ MAC Verification - + - + - + - - - + + - - - + +
+ + + +
+ bgcolor="#3366ff" height="90"> +

MAC Verification
-

-
-
-
- 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. -
-
- Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC - - module name ipt_mac.o).
-
- There are four components to this facility.
- +
+ 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. +
+
+ Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC + - module name ipt_mac.o).
+
+ There are four components to this facility.
+
    -
  1. The maclist interface option in 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 The maclist option in /etc/shorewall/hosts. When this option - is specified for a subnet, all traffic from that subnet is subject to + 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 /etc/shorewall/maclist file. This file is used to associate + MAC addresses with interfaces and to optionally associate IP addresses + with MAC addresses.
    6. +
  6. 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.
    +
    7. +
- 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 the device whose MAC is listed in the MAC column.
    • - +
  • 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:
- + +

Example 1: Here are my files (look here for +details about my setup):

+ /etc/shorewall/shorewall.conf:
+ 
     MACLIST_DISPOSITION=REJECT
     MACLIST_LOG_LEVEL=info
- /etc/shorewall/interfaces:
- -
- 
#ZONE   INTERFACE        BROADCAST       OPTIONS
net     eth0            206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
loc     eth2            192.168.1.255   dhcp
dmz     eth1            192.168.2.255
wap     eth3            192.168.3.255   dhcp,maclist
-       texas           192.168.9.255
-
- /etc/shorewall/maclist:
- -
- 
#INTERFACE              MAC                     IP ADDRESSES (Optional)
eth3                    00:A0:CC:A2:0C:A0       192.168.3.7     #Work Laptop
eth3                    00:04:5a:fe:85:b9       192.168.3.250   #WAP11
eth3                    00:06:25:56:33:3c                       #WET11
eth3                    00:0b:cd:C4:cc:97       192.168.3.8     #TIPPER
-
- As shown above, I use MAC Verification on my wireless zone.
-
-Note: The WET11 is a somewhat curious device; when forwarding DHCP -traffic, it uses the MAC address of the host (TIPPER) but for other forwarded -traffic it uses it's own MAC address. Consequently, I don't assign the WET11 -a fixed IP address in /etc/shorewall/maclist.
- -

Example 2: Router in Local Zone

- Suppose now that I add a second wireless segment to my wireless -zone and gateway that segment via a router with MAC address 00:06:43:45:C6:15 - and IP address 192.168.3.253. Hosts in the second segment have IP addresses - in the subnet 192.168.4.0/24. I would add the following entry to my /etc/shorewall/maclist - file:
- + /etc/shorewall/interfaces:
+ +
+ 
#ZONE   INTERFACE        BROADCAST       OPTIONS
net     eth0            206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
loc     eth2            192.168.1.255   dhcp
dmz     eth1            192.168.2.255
WiFi    eth3            192.168.3.255   dhcp,maclist
-       texas           192.168.9.255
+
+ /etc/shorewall/maclist:
+ +
+ 
#INTERFACE              MAC                     IP ADDRESSES (Optional)
eth3                    00:A0:CC:A2:0C:A0       192.168.3.7                 #Work Laptop
eth3                    00:04:5a:fe:85:b9       192.168.3.250               #WAP11
eth3                    00:06:25:56:33:3c       192.168.3.225,192.168.3.8   #WET11
eth3                    00:0b:cd:C4:cc:97       192.168.3.8                 #TIPPER
+
+ As shown above, I use MAC Verification on my wireless zone.
+
+ Note: While marketed as a wireless bridge, the WET11 behaves like +a wireless router with DHCP relay. When forwarding DHCP traffic, it uses the +MAC address of the host (TIPPER) but for other forwarded traffic it uses it's +own MAC address. Consequently, I list the IP addresses of both devices in +/etc/shorewall/maclist.
+ +

Example 2: Router in Wireless Zone

+ Suppose now that I add a second wireless segment to my wireless + zone and gateway that segment via a router with MAC address 00:06:43:45:C6:15 + and IP address 192.168.3.253. Hosts in the second segment have IP addresses + in the subnet 192.168.4.0/24. I would add the following entry to my /etc/shorewall/maclist + file:
+ 
     eth3                     00:06:43:45:C6:15       192.168.3.253,192.168.4.0/24
- This entry accomodates traffic from the router itself (192.168.3.253) - and from the second wireless segment (192.168.4.0/24). Remember that + This entry accomodates traffic from the router itself (192.168.3.253) + and from the second wireless segment (192.168.4.0/24). Remember that all traffic being sent to my firewall from the 192.168.4.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 6/10/2002 - Tom Eastep -

- +the traffic. +

Updated 6/30/2002 - Tom Eastep +

+

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

+ 2001, 2002, 2003 Thomas M. Eastep.
+

+
+



diff --git a/STABLE/documentation/NAT.htm b/STABLE/documentation/NAT.htm index eb4530c3a..dec289ba3 100644 --- a/STABLE/documentation/NAT.htm +++ b/STABLE/documentation/NAT.htm @@ -1,117 +1,119 @@ - + Shorewall NAT - + - + - -
- - - - - - - -
-

Static NAT

-
- -

IMPORTANT: If all you want to do is forward - ports to servers behind your firewall, you do NOT want to use static -NAT. Port forwarding can be accomplished with simple entries in the - rules file.

- -

Static NAT is a way to make systems behind a firewall and configured -with private IP addresses (those reserved for private use in RFC1918) -appear to have public IP addresses. Before you try to use this technique, -I strongly recommend that you read the + + + +

Static Nat

+ + + + + +
+
+ +

IMPORTANT: If all you want to do is forward + ports to servers behind your firewall, you do NOT want to use static + NAT. Port forwarding can be accomplished with simple entries in the + rules file.

+
+

Static NAT is a way to make systems behind a firewall and configured + with private IP addresses (those reserved for private use in RFC1918) + appear to have public IP addresses. Before you try to use this technique, + I strongly recommend that you read the Shorewall Setup Guide.

- -

The following figure represents a static NAT environment.

- +
+

The following figure represents a static NAT environment.

+

-

- +

+
- -

Static NAT can be used to make the systems with the 10.1.1.* -addresses appear to be on the upper (130.252.100.*) subnet. If we assume -that the interface to the upper subnet is eth0, then the following /etc/shorewall/NAT -file would make the lower left-hand system appear to have IP address +

+

Static NAT can be used to make the systems with the 10.1.1.* + addresses appear to be on the upper (130.252.100.*) subnet. If we assume + that the interface to the upper subnet is eth0, then the following /etc/shorewall/NAT + file would make the lower left-hand system appear to have IP address 130.252.100.18 and the right-hand one to have IP address 130.252.100.19.

- - - - - - - - - - - - - - - - - - - - - - - - - - -
EXTERNALINTERFACEINTERNALALL INTERFACESLOCAL
130.252.100.18eth010.1.1.2yesyes
130.252.100.19eth010.1.1.3yesyes
- -

Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above - example) is (are) not included in any specification in /etc/shorewall/masq - or /etc/shorewall/proxyarp.

- -

Note 1: The "ALL INTERFACES" column is used -to specify whether access to the external IP from all firewall interfaces -should undergo NAT (Yes or yes) or if only access from the interface in -the INTERFACE column should undergo NAT. If you leave this column empty, -"Yes" is assumed. The ALL INTERFACES column was added in version 1.1.6.

- -

Note 2: Shorewall will automatically add the external address to the + + + + + + + + + + + + + + + + + + + + + + + + + + +
EXTERNALINTERFACEINTERNALALL INTERFACESLOCAL
130.252.100.18eth010.1.1.2yesyes
130.252.100.19eth010.1.1.3yesyes
+ +

Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above + example) is (are) not included in any specification in /etc/shorewall/masq + or /etc/shorewall/proxyarp.

+ +

Note 1: The "ALL INTERFACES" column is used + to specify whether access to the external IP from all firewall interfaces + should undergo NAT (Yes or yes) or if only access from the interface in + the INTERFACE column should undergo NAT. If you leave this column empty, + "Yes" is assumed. The ALL INTERFACES column was added in version 1.1.6.

+ +

Note 2: Shorewall will automatically add the external address to the specified interface unless you specify ADD_IP_ALIASES="no" (or "No") in -/etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if -you set it to "Yes" or "yes" then you must NOT configure your own alias(es). - RESTRICTION: Shorewall can only add external addresses to an interface -that is configured with a single subnetwork -- if your external interface -has addresses in more than one subnetwork, Shorewall can only add addresses -to the first one.

- -

Note 3: The contents of the "LOCAL" column -determine whether packets originating on the firewall itself and destined -for the EXTERNAL address are redirected to the internal ADDRESS. If this -column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN also contains -"Yes" or "yes") then such packets are redirected; otherwise, such packets -are not redirected. The LOCAL column was added in version 1.1.8.

-
- + href="Documentation.htm#Aliases">ADD_IP_ALIASES="no" (or "No") in + /etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or +if you set it to "Yes" or "yes" then you must NOT configure your own alias(es). + RESTRICTION: Shorewall versions earlier than 1.4.6 can only add + external addresses to an interface that is configured with a single subnetwork + -- if your external interface has addresses in more than one subnetwork, +Shorewall 1.4.5 and earlier can only add addresses to the first one.

+ +

Note 3: The contents of the "LOCAL" column + determine whether packets originating on the firewall itself and destined + for the EXTERNAL address are redirected to the internal ADDRESS. If + this column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN +also contains "Yes" or "yes") then such packets are redirected; otherwise, +such packets are not redirected. The LOCAL column was added in version +1.1.8.

+
- -

Last updated 4/11/2003 - Last updated 7/6/2003 - Tom Eastep

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

diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 2d1316734..2d61645c1 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -4,7 +4,8 @@ - + + Shorewall News @@ -14,3358 +15,4311 @@ - + + - + + - + + + id="AutoNumber1" bgcolor="#3366ff" height="90"> - + - + - + - + - - - + + + +
+ - +

Shorewall News Archive

-
- -

6/17/2003 - Shorewall-1.4.5

-

Problems Corrected:
-

-
    -
  1. The command "shorewall debug try <directory>" now correctly traces -the attempt.
    2. -
  2. The INCLUDE directive now works properly in the zones file; previously, -INCLUDE in that file was ignored.
    3. -
  3. /etc/shorewall/routestopped records with an empty second column are -no longer ignored.
    -
    4. -
-

New Features:
-

-
    -
  1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now contain -a list of addresses. If the list begins with "!' then the rule will take -effect only if the original destination address in the connection request -does not match any of the addresses listed.
    2. -
-

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

- -

The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and -iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems -have been encountered with this set of software. The Shorewall version is -1.4.4b plus the accumulated changes for 1.4.5.
-

- -

6/8/2003 - Updated Samples

- -

Thanks to Francesca Smith, the samples have been updated to Shorewall -version 1.4.4.

- -

5/29/2003 - Shorewall-1.4.4b

- -

Groan -- This version corrects a problem whereby the --log-level was not - being set when logging via syslog. The most commonly reported symptom was - that Shorewall messages were being written to the console even though console - logging was correctly configured per FAQ 16.
-

- -

5/27/2003 - Shorewall-1.4.4a

- The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed - out that the code in 1.4.4 restricts the length of short zone names to -4 characters. I've produced version 1.4.4a that restores the previous 5-character - limit by conditionally omitting the log rule number when the LOGFORMAT -doesn't contain '%d'.
+ -

5/23/2003 - Shorewall-1.4.4

- I apologize for the rapid-fire releases but since there is a potential - configuration change required to go from 1.4.3a to 1.4.4, I decided to -make it a full release rather than just a bug-fix release.
-
-     Problems corrected:
- -
None.
-
-     New Features:
- -
    -
  1. A REDIRECT- rule target has been added. This target behaves -for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter -nat table REDIRECT rule is added but not the companion filter table ACCEPT -rule.
    -
    -
    2. -
  2. The LOGMARKER variable has been renamed LOGFORMAT and has been - changed to a 'printf' formatting template which accepts three arguments - (the chain name, logging rule number and the disposition). To use LOGFORMAT - with fireparse (http://www.fireparse.com), - set it as:
    -  
    -        LOGFORMAT="fp=%s:%d a=%s "
    -  
    - CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT - string (up to but not including the first '%') to find log messages in -the 'show log', 'status' and 'hits' commands. This part should not be omitted - (the LOGFORMAT should not begin with "%") and the leading part should be - sufficiently unique for /sbin/shorewall to identify Shorewall messages.
    -
    -
    3. -
  3. When logging is specified on a DNAT[-] or REDIRECT[-] rule, -the logging now takes place in the nat table rather than in the filter -table. This way, only those connections that actually undergo DNAT or -redirection will be logged.
    -
    4. - -
- -

5/20/2003 - Shorewall-1.4.3a
-

- This version primarily corrects the documentation included in the - .tgz and in the .rpm. In addition:
- -
    -
  1. (This change is in 1.4.3 but is not documented) If you are -running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject -replies as follows:
    -    a) tcp - RST
    -    b) udp - ICMP port unreachable
    -    c) icmp - ICMP host unreachable
    -    d) Otherwise - ICMP host prohibited
    - If you are running earlier software, Shorewall will follow it's -traditional convention:
    -    a) tcp - RST
    -    b) Otherwise - ICMP port unreachable
    2. -
  2. UDP port 135 is now silently dropped in the common.def chain. - Remember that this chain is traversed just before a DROP or REJECT policy - is enforced.
    -
    3. - -
- -

5/18/2003 - Shorewall 1.4.3
-

-     Problems Corrected:
- -
    -
  1. There were several cases where Shorewall would fail to remove - a temporary directory from /tmp. These cases have been corrected.
    2. -
  2. The rules for allowing all traffic via the loopback interface - have been moved to before the rule that drops status=INVALID packets. -This insures that all loopback traffic is allowed even if Netfilter connection - tracking is confused.
    3. - -
-     New Features:
- -
    -
  1.  IPV6-IPV4 (6to4) tunnels are now supported in the /etc/shorewall/tunnels - file.
    2. -
  2. You may now change the leading portion of the --log-prefix - used by Shorewall using the LOGMARKER variable in shorewall.conf. By default, - "Shorewall:" is used.
    -
    3. - -
- -

5/10/2003 - Shorewall Mirror in Asia
-

- -

Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
-

- -

5/8/2003 - Shorewall Mirror in Chile

- Thanks to Darcy Ganga, there is now an HTTP mirror in -Santiago Chile. -

4/21/2003 - Samples updated for Shorewall version 1.4.2

- -

Thanks to Francesca Smith, the sample configurations are now upgraded to -Shorewall version 1.4.2.

- -

4/9/2003 - Shorewall 1.4.2
-

- -

    Problems Corrected:

- -
-
    -
  1. TCP connection requests rejected out of the common - chain are now properly rejected with TCP RST; previously, some of -these requests were rejected with an ICMP port-unreachable response.
    2. -
  2. 'traceroute -I' from behind the firewall previously - timed out on the first hop (e.g., to the firewall). This has been -worked around.
    3. - -
-
- -

    New Features:

- -
    -
  1. Where an entry in the/etc/shorewall/hosts file specifies - a particular host or network, Shorewall now creates an intermediate - chain for handling input from the related zone. This can substantially - reduce the number of rules traversed by connections requests from such - zones.
    -
    -
    2. -
  2. Any file may include an INCLUDE directive. An INCLUDE - directive consists of the word INCLUDE followed by a file name and -causes the contents of the named file to be logically included into -the file containing the INCLUDE. File names given in an INCLUDE directive -are assumed to reside in /etc/shorewall or in an alternate configuration - directory if one has been specified for the command.
    -  
    -    Examples:
    -    shorewall/params.mgmt:
    -    MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
    -    TIME_SERVERS=4.4.4.4
    -    BACKUP_SERVERS=5.5.5.5
    -    ----- end params.mgmt -----
    -  
    -  
    -    shorewall/params:
    -    # Shorewall 1.3 /etc/shorewall/params
    -    [..]
    -    #######################################
    -  
    -    INCLUDE params.mgmt   
    -  
    -    # params unique to this host here
    -    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT -REMOVE
    -    ----- end params -----
    -  
    -  
    -    shorewall/rules.mgmt:
    -    ACCEPT net:$MGMT_SERVERS          $FW    tcp    22
    -    ACCEPT $FW          net:$TIME_SERVERS    udp    123
    -    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    22
    -    ----- end rules.mgmt -----
    -  
    -    shorewall/rules:
    -    # Shorewall version 1.3 - Rules File
    -    [..]
    -    #######################################
    -  
    -    INCLUDE rules.mgmt    
    -  
    -    # rules unique to this host here
    -    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO -NOT REMOVE
    -    ----- end rules -----
    -  
    - INCLUDE's may be nested to a level of 3 -- further nested - INCLUDE directives are ignored with a warning message.
    -
    -
    3. -
  3. Routing traffic from an interface back out that interface - continues to be a problem. While I firmly believe that this should - never happen, people continue to want to do it. To limit the damage -that such nonsense produces, I have added a new 'routeback' option in -/etc/shorewall/interfaces and /etc/shorewall/hosts. When used in /etc/shorewall/interfaces, -the 'ZONE' column may not contain '-'; in other words, 'routeback' can't - be used as an option for a multi-zone interface. The 'routeback' option - CAN be specified however on individual group entries in /etc/shorewall/hosts.
    -  
    - The 'routeback' option is similar to the old 'multi' option - with two exceptions:
    -  
    -    a) The option pertains to a particular zone,interface,address - tuple.
    -  
    -    b) The option only created infrastructure to pass traffic - from (zone,interface,address) tuples back to themselves (the 'multi' - option affected all (zone,interface,address) tuples associated with - the given 'interface').
    -  
    - See the 'Upgrade Issues' - for information about how this new option may affect your configuration.
    -
    4. - -
- -

3/24/2003 - Shorewall 1.4.1

- +

7/20/2003 - Shorewall-1.4.6
+

- - - - - - - - - - - - - - - - - - -

This release follows up on 1.4.0. It corrects a problem introduced in -1.4.0 and removes additional warts.
-
- Problems Corrected:
-

- -
    -
  1. When Shorewall 1.4.0 is run under the ash shell (such - as on Bering/LEAF), it can attempt to add ECN disabling rules even -if the /etc/shorewall/ecn file is empty. That problem has been corrected - so that ECN disabling rules are only added if there are entries in -/etc/shorewall/ecn.
    2. - -
- New Features:
- -
Note: In the list that follows, the term group refers to -a particular network or subnetwork (which may be 0.0.0.0/0 or it may be a -host address) accessed through a particular interface. Examples:
- -
eth0:0.0.0.0/0
- eth2:192.168.1.0/24
- eth3:192.0.2.123
-
- You can use the "shorewall check" command to see the groups - associated with each of your zones.
-
- -
    -
  1. Beginning with Shorewall 1.4.1, if a zone Z comprises - more than one group then if there is no explicit Z to Z policy - and there are no rules governing traffic from Z to Z then Shorewall will - permit all traffic between the groups in the zone.
    2. -
  2. Beginning with Shorewall 1.4.1, Shorewall will never - create rules to handle traffic from a group to itself.
    3. -
  3. A NONE policy is introduced in 1.4.1. When a policy -of NONE is specified from Z1 to Z2:
    4. - -
- -
    -
  • There may be no rules created that govern connections - from Z1 to Z2.
    • -
  • Shorewall will not create any infrastructure to handle - traffic from Z1 to Z2.
    • - -
- See the upgrade issues -for a discussion of how these changes may affect your configuration. - -

3/17/2003 - Shorewall 1.4.0

- Shorewall - 1.4 represents the next step in the evolution of Shorewall. The - main thrust of the initial release is simply to remove the cruft that - has accumulated in Shorewall over time.
-
- IMPORTANT: Shorewall 1.4.0 requires the iproute - package ('ip' utility).
-
- Function from 1.3 that has been omitted from this - version include:
- -
    -
  1. The MERGE_HOSTS variable in shorewall.conf - is no longer supported. Shorewall 1.4 behavior is the same as 1.3 - with MERGE_HOSTS=Yes.
    -
    -
    2. -
  2. Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate an error.
    -
    -
    3. -
  3. Shorewall 1.4 implements behavior consistent - with OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate - an error at startup as will specification of the 'noping' or 'filterping' - interface options.
    -
    -
    4. -
  4. The 'routestopped' option in the /etc/shorewall/interfaces - and /etc/shorewall/hosts files is no longer supported and will - generate an error at startup if specified.
    -
    -
    5. -
  5. The Shorewall 1.2 syntax for DNAT and REDIRECT - rules is no longer accepted.
    -
    -
    6. -
  6. The ALLOWRELATED variable in shorewall.conf - is no longer supported. Shorewall 1.4 behavior is the same as -1.3 with ALLOWRELATED=Yes.
    -
    -
    7. -
  7. The icmp.def file has been removed.
    -
    8. - -
- Changes for 1.4 include:
- -
    -
  1. The /etc/shorewall/shorewall.conf file has -been completely reorganized into logical sections.
    -
    -
    2. -
  2. LOG is now a valid action for a rule (/etc/shorewall/rules).
    -
    -
    3. -
  3. The firewall script and version file are now - installed in /usr/share/shorewall.
    -
    -
    4. -
  4. Late arriving DNS replies are now silently -dropped in the common chain by default.
    -
    -
    5. -
  5. In addition to behaving like OLD_PING_HANDLING=No, - Shorewall 1.4 no longer unconditionally accepts outbound ICMP -packets. So if you want to 'ping' from the firewall, you will need -the appropriate rule or policy.
    -
    -
    6. -
  6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
    -
    -
    7. -
  7. 802.11b devices with names of the form wlan<n> - now support the 'maclist' option.
    -
    -
    8. -
  8. Explicit Congestion Notification (ECN - RFC 3168) - may now be turned off on a host or network basis using the new /etc/shorewall/ecn - file. To use this facility:
    -
    -    a) You must be running kernel 2.4.20
    -    b) You must have applied the patch in
    -    http://www.shorewall/net/pub/shorewall/ecn/patch.
    -    c) You must have iptables 1.2.7a installed.
    -
    -
    9. -
  9. The /etc/shorewall/params file is now processed -first so that variables may be used in the /etc/shorewall/shorewall.conf - file.
    -
    -
    10. -
  10. Shorewall now gives a more helpful diagnostic - when the 'ipchains' compatibility kernel module is loaded and a -'shorewall start' command is issued.
    -
    -
    11. -
  11. The SHARED_DIR variable has been removed from shorewall.conf. - This variable was for use by package maintainers and was not documented - for general use.
    -
    -
    12. -
  12. Shorewall now ignores 'default' routes when detecting - masq'd networks.
    13. - -
- -

3/10/2003 - Shoreall 1.3.14a

- -

A roleup of the following bug fixes and other updates:

- -
    -
  • There is an updated rfc1918 file that reflects the -resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • - -
-
    -
  • The documentation for the routestopped file claimed - that a comma-separated list could appear in the second column -while the code only supported a single host or network address.
    • -
  • Log messages produced by 'logunclean' and 'dropunclean' - were not rate-limited.
    • -
  • 802.11b devices with names of the form wlan<n> - don't support the 'maclist' interface option.
    • -
  • Log messages generated by RFC 1918 filtering are not - rate limited.
    • -
  • The firewall fails to start in the case where you -have "eth0 eth1" in /etc/shorewall/masq and the default route is through - eth1
    • +
    + +

    Problems Corrected:
    +

    + + +
      +
    1. A problem seen on RH7.3 systems where Shorewall encountered start + errors when started using the "service" mechanism has been worked around.
      +
      +
      2. +
    2. Where a list of IP addresses appears in the DEST column of a DNAT[-] + rule, Shorewall incorrectly created multiple DNAT rules in the nat table +(one for each element in the list). Shorewall now correctly creates a +single DNAT rule with multiple "--to-destination" clauses.
      +
      +
      3. +
    3. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a rule.
      +
      +
      4. +
    4. A number of problems with rule parsing have been corrected. Corrections +involve the handling of "z1!z2" in the SOURCE column as well as lists in +the ORIGINAL DESTINATION column.
      +
      +
      5. +
    5. The message "Adding rules for DHCP" is now suppressed if there are +no DHCP rules to add.
      +
      6. +
    + + +

    Migration Issues:
    +

    + +
      +
    1. In earlier versions, an undocumented feature allowed entries in +the host file as follows:
      +
      +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 + to allow entries of the following format:
      +
      +     z   eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      2. +
    2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been + removed from /etc/shorewall/shorewall.conf. These capabilities are now +automatically detected by Shorewall (see below).
      +
      3. +
    + +

    New Features:
    +

    + + +
      +
    1. A 'newnotsyn' interface option has been added. This option may +be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No + for packets arriving on the associated interface.
      +
      +
      2. +
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for + address ranges.
      +
      +
      3. +
    3. Shorewall can now add IP addresses to subnets other than the first + one on an interface.
      +
      +
      4. +
    4. DNAT[-] rules may now be used to load balance (round-robin) over +a set of servers. Servers may be specified in a range of addresses given +as <first address>-<last address>.
      +
      + Example:
      +
      +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +
      +
      5. +
    5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options + have been removed and have been replaced by code that detects whether + these capabilities are present in the current kernel. The output of the + start, restart and check commands have been enhanced to report the outcome:
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      + Verifying Configuration...
      +
      +
      6. +
    6. Support for the Connection Tracking Match Extension has been added. + This extension is available in recent kernel/iptables releases and allows + for rules which match against elements in netfilter's connection tracking + table. Shorewall automatically detects the availability of this extension + and reports its availability in the output of the start, restart and +check commands.
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      +    Connection Tracking Match: Available
      + Verifying Configuration...
      +
      + If this extension is available, the ruleset generated by Shorewall + is changed in the following ways:
      7. +
        +
      • To handle 'norfc1918' filtering, Shorewall will not create chains + in the mangle table but will rather do all 'norfc1918' filtering in the +filter table (rfc1918 chain).
        • +
      • Recall that Shorewall DNAT rules generate two netfilter rules; + one in the nat table and one in the filter table. If the Connection +Tracking Match Extension is available, the rule in the filter table is extended + to check that the original destination address was the same as specified + (or defaulted to) in the DNAT rule.
        +
        +
        • +
      +
    7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      +
      +
      8. +
    8. An 'ipcalc' command has been added to /sbin/shorewall.
      +
      +       ipcalc [ <address> <netmask> | <address>/<vlsm> + ]
      +
      + Examples:
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      + Warning:
      +
      + If your shell only supports 32-bit signed arithmatic (ash or dash), + then the ipcalc command produces incorrect information for IP addresses + 128.0.0.0-1 and for /1 networks. Bash should produce correct information + for all valid IP addresses.
      +
      +
      9. +
    9. An 'iprange' command has been added to /sbin/shorewall. +
      +
      +       iprange <address>-<address>
      +
      + This command decomposes a range of IP addressses into a list of +network and host addresses. The command can be useful if you need to construct + an efficient set of rules that accept connections from a range of network + addresses.
      +
      + Note: If your shell only supports 32-bit signed arithmetic (ash +or dash) then the range may not span 128.0.0.0.
      +
      + Example:
      +
      +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      +       192.168.1.4/30
      +       192.168.1.8/29
      +       192.168.1.16/28
      +       192.168.1.32/27
      +       192.168.1.64/26
      +       192.168.1.128/25
      +       192.168.2.0/23
      +       192.168.4.0/22
      +       192.168.8.0/22
      +       192.168.12.0/29
      +       192.168.12.8/31
      +       [root@gateway root]#
      +
      +
      10. +
    10. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
      +
      + Example:
      +
      +     foo    eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      11. +
    11. The "shorewall check" command now includes the chain name when printing +the applicable policy for each pair of zones.
      +  
      +     Example:
      +  
      +         Policy for dmz to net is REJECT using chain all2all
      +  
      + This means that the policy for connections from the dmz to the internet +is REJECT and the applicable entry in the /etc/shorewall/policy was the all->all +policy.
      +
      +
      12. +
    12. Support for the 2.6 Kernel series has been added.
      +
      13. +
    +

    7/15/2003 - New Mirror in Brazil
    +

    + Thanks to the folks at securityopensource.org.br, there is now a Shorewall + mirror in Brazil. +

    7/15/2003 - Shorewall-1.4.6 RC 1
    +

    + +

    Problems Corrected:
    +

    + +
      +
    1. A problem seen on RH7.3 systems where Shorewall encountered start + errors when started using the "service" mechanism has been worked around.
      +
      +
      2. +
    2. Where a list of IP addresses appears in the DEST column of a DNAT[-] + rule, Shorewall incorrectly created multiple DNAT rules in the nat table + (one for each element in the list). Shorewall now correctly creates a single + DNAT rule with multiple "--to-destination" clauses.
      +
      +
      3. +
    3. Corrected a problem in Beta 1 where DNS names containing a "-" were + mis-handled when they appeared in the DEST column of a rule.
      +
      +
      4. +
    4. A number of problems with rule parsing have been corrected. Corrections + involve the handling of "z1!z2" in the SOURCE column as well as lists in +the ORIGINAL DESTINATION column.
      +
      5. + +
    + +

    Migration Issues:
    +

    + +
      +
    1. In earlier versions, an undocumented feature allowed entries in +the host file as follows:
      +
      +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 to + allow entries of the following format:
      +
      +     z   eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      2. +
    2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically + detected by Shorewall (see below).
      +
      3. + +
    + +

    New Features:
    +

    + +
      +
    1. A 'newnotsyn' interface option has been added. This option may be + specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No + for packets arriving on the associated interface.
      +
      +
      2. +
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for +address ranges.
      +
      +
      3. +
    3. Shorewall can now add IP addresses to subnets other than the first + one on an interface.
      +
      +
      4. +
    4. DNAT[-] rules may now be used to load balance (round-robin) over +a set of servers. Servers may be specified in a range of addresses given + as <first address>-<last address>.
      +
      + Example:
      +
      +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +
      +
      5. +
    5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options + have been removed and have been replaced by code that detects whether +these capabilities are present in the current kernel. The output of the +start, restart and check commands have been enhanced to report the outcome:
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      + Verifying Configuration...
      +
      +
      6. +
    6. Support for the Connection Tracking Match Extension has been added. + This extension is available in recent kernel/iptables releases and allows + for rules which match against elements in netfilter's connection tracking + table. Shorewall automatically detects the availability of this extension + and reports its availability in the output of the start, restart and check + commands.
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      +    Connection Tracking Match: Available
      + Verifying Configuration...
      +
      + If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
      7. + +
        +
      • To handle 'norfc1918' filtering, Shorewall will not create chains + in the mangle table but will rather do all 'norfc1918' filtering in the +filter table (rfc1918 chain).
        • +
      • Recall that Shorewall DNAT rules generate two netfilter rules; +one in the nat table and one in the filter table. If the Connection Tracking + Match Extension is available, the rule in the filter table is extended +to check that the original destination address was the same as specified +(or defaulted to) in the DNAT rule.
        +
        +
        • + +
      +
    7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      +
      +
      8. +
    8. An 'ipcalc' command has been added to /sbin/shorewall.
      +
      +       ipcalc [ <address> <netmask> | <address>/<vlsm> + ]
      +
      + Examples:
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      + Warning:
      +
      + If your shell only supports 32-bit signed arithmatic (ash or dash), +then the ipcalc command produces incorrect information for IP addresses +128.0.0.0-1 and for /1 networks. Bash should produce correct information +for all valid IP addresses.
      +
      +
      9. +
    9. An 'iprange' command has been added to /sbin/shorewall.
      +
      +       iprange <address>-<address>
      +
      + This command decomposes a range of IP addressses into a list of network + and host addresses. The command can be useful if you need to construct +an efficient set of rules that accept connections from a range of network +addresses.
      +
      + Note: If your shell only supports 32-bit signed arithmetic (ash or dash) + then the range may not span 128.0.0.0.
      +
      + Example:
      +
      +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      +       192.168.1.4/30
      +       192.168.1.8/29
      +       192.168.1.16/28
      +       192.168.1.32/27
      +       192.168.1.64/26
      +       192.168.1.128/25
      +       192.168.2.0/23
      +       192.168.4.0/22
      +       192.168.8.0/22
      +       192.168.12.0/29
      +       192.168.12.8/31
      +       [root@gateway root]#
      +
      +
      10. +
    10. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
      +
      + Example:
      +
      +     foo    eth1:192.168.1.0/24,192.168.2.0/24
      11. + +
    + +

    7/7/2003 - Shorewall-1.4.6 Beta 2

    + +

    Problems Corrected:
    +

    + +
      +
    1. A problem seen on RH7.3 systems where Shorewall encountered start + errors when started using the "service" mechanism has been worked around.
      +
      +
      2. +
    2. Where a list of IP addresses appears in the DEST column of a DNAT[-] + rule, Shorewall incorrectly created multiple DNAT rules in the nat table + (one for each element in the list). Shorewall now correctly creates a single + DNAT rule with multiple "--to-destination" clauses.
      +
      +
      3. +
    3. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a rule.
      +
      4. + +
    + +

    Migration Issues:
    +

    + +
      +
    1. In earlier versions, an undocumented feature allowed entries in +the host file as follows:
      +
      +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 to +allow entries of the following format:
      +
      +     z   eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      2. +
    2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically + detected by Shorewall (see below).
      +
      3. + +
    + +

    New Features:
    +

    + +
      +
    1. A 'newnotsyn' interface option has been added. This option may +be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No + for packets arriving on the associated interface.
      +
      +
      2. +
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for +address ranges.
      +
      +
      3. +
    3. Shorewall can now add IP addresses to subnets other than the first + one on an interface.
      +
      +
      4. +
    4. DNAT[-] rules may now be used to load balance (round-robin) over + a set of servers. Servers may be specified in a range of addresses given + as <first address>-<last address>.
      +
      + Example:
      +
      +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +
      +
      5. +
    5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options + have been removed and have been replaced by code that detects whether +these capabilities are present in the current kernel. The output of the +start, restart and check commands have been enhanced to report the outcome:
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      + Verifying Configuration...
      +
      +
      6. +
    6. Support for the Connection Tracking Match Extension has been added. + This extension is available in recent kernel/iptables releases and allows + for rules which match against elements in netfilter's connection tracking + table. Shorewall automatically detects the availability of this extension + and reports its availability in the output of the start, restart and check + commands.
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      +    Connection Tracking Match: Available
      + Verifying Configuration...
      +
      + If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
      7. + +
        +
      • To handle 'norfc1918' filtering, Shorewall will not create chains + in the mangle table but will rather do all 'norfc1918' filtering in the + filter table (rfc1918 chain).
        • +
      • Recall that Shorewall DNAT rules generate two netfilter rules; + one in the nat table and one in the filter table. If the Connection Tracking + Match Extension is available, the rule in the filter table is extended +to check that the original destination address was the same as specified +(or defaulted to) in the DNAT rule.
        +
        +
        • + +
      +
    7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      +
      +
      8. +
    8. An 'ipcalc' command has been added to /sbin/shorewall.
      +
      +       ipcalc [ <address> <netmask> | <address>/<vlsm> + ]
      +
      + Examples:
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      + Warning:
      +
      + If your shell only supports 32-bit signed arithmatic (ash or dash), then + the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1 + and for /1 networks. Bash should produce correct information for all valid + IP addresses.
      +
      +
      9. +
    9. An 'iprange' command has been added to /sbin/shorewall.
      +
      +       iprange <address>-<address>
      +
      + This command decomposes a range of IP addressses into a list of network + and host addresses. The command can be useful if you need to construct an + efficient set of rules that accept connections from a range of network addresses.
      +
      + Note: If your shell only supports 32-bit signed arithmetic (ash or dash) + then the range may not span 128.0.0.0.
      +
      + Example:
      +
      +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      +       192.168.1.4/30
      +       192.168.1.8/29
      +       192.168.1.16/28
      +       192.168.1.32/27
      +       192.168.1.64/26
      +       192.168.1.128/25
      +       192.168.2.0/23
      +       192.168.4.0/22
      +       192.168.8.0/22
      +       192.168.12.0/29
      +       192.168.12.8/31
      +       [root@gateway root]#
      +
      +
      10. +
    10. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
      +
      + Example:
      +
      +     foo    eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      11. + +
    + +

    7/4/2003 - Shorewall-1.4.6 Beta 1

    + +

    Problems Corrected:
    +

    + +
      +
    1. A problem seen on RH7.3 systems where Shorewall encountered start + errors when started using the "service" mechanism has been worked around.
      +
      +
      2. +
    2. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the +nat table (one for each element in the list). Shorewall now correctly creates +a single DNAT rule with multiple "--to-destination" clauses.
      +
      3. + +
    + +

    New Features:
    +

    + +
      +
    1. A 'newnotsyn' interface option has been added. This option may + be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No + for packets arriving on the associated interface.
      +
      +
      2. +
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for +address ranges.
      +
      +
      3. +
    3. Shorewall can now add IP addresses to subnets other than the +first one on an interface.
      +
      +
      4. +
    4. DNAT[-] rules may now be used to load balance (round-robin) over + a set of servers. Up to 256 servers may be specified in a range of addresses + given as <first address>-<last address>.
      +
      + Example:
      +
      +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +
      + Note that this capability has previously been available using a combination + of a DNAT- rule and one or more ACCEPT rules. That technique is still +preferable for load-balancing over a large number of servers (> 16) +since specifying a range in the DNAT rule causes one filter table ACCEPT +rule to be generated for each IP address in the range.
      +
      +
      5. +
    5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options + have been removed and have been replaced by code that detects whether +these capabilities are present in the current kernel. The output of the +start, restart and check commands have been enhanced to report the outcome:
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      + Verifying Configuration...
      +
      +
      6. +
    6. Support for the Connection Tracking Match Extension has been +added. This extension is available in recent kernel/iptables releases +and allows for rules which match against elements in netfilter's connection +tracking table. Shorewall automatically detects the availability of this +extension and reports its availability in the output of the start, restart +and check commands.
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      +    Connection Tracking Match: Available
      + Verifying Configuration...
      +
      + If this extension is available, the ruleset generated by Shorewall +is changed in the following ways:
      7. + +
        + +
      + +
        +
      • To handle 'norfc1918' filtering, Shorewall will not create +chains in the mangle table but will rather do all 'norfc1918' filtering +in the filter table (rfc1918 chain).
        • +
      • Recall that Shorewall DNAT rules generate two netfilter rules; + one in the nat table and one in the filter table. If the Connection Tracking + Match Extension is available, the rule in the filter table is extended +to check that the original destination address was the same as specified +(or defaulted to) in the DNAT rule.
        +
        +
        • + +
      +
    7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      +
      8. + +
    + +

    6/17/2003 - Shorewall-1.4.5

    + +

    Problems Corrected:
    +

    + +
      +
    1. The command "shorewall debug try <directory>" now correctly + traces the attempt.
      2. +
    2. The INCLUDE directive now works properly in the zones file; +previously, INCLUDE in that file was ignored.
      3. +
    3. /etc/shorewall/routestopped records with an empty second column + are no longer ignored.
      +
      4. + +
    + +

    New Features:
    +

    + +
      +
    1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may + now contain a list of addresses. If the list begins with "!' then the +rule will take effect only if the original destination address in the +connection request does not match any of the addresses listed.
      2. + +
    + +

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

    + +

    The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and + iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems + have been encountered with this set of software. The Shorewall version + is 1.4.4b plus the accumulated changes for 1.4.5.
    +

    + +

    6/8/2003 - Updated Samples

    + +

    Thanks to Francesca Smith, the samples have been updated to Shorewall version +1.4.4.

    + +

    5/29/2003 - Shorewall-1.4.4b

    + +

    Groan -- This version corrects a problem whereby the --log-level was not + being set when logging via syslog. The most commonly reported symptom + was that Shorewall messages were being written to the console even though + console logging was correctly configured per FAQ 16.
    +

    + +

    5/27/2003 - Shorewall-1.4.4a

    + The Fireparse --log-prefix fiasco continues. Tuomo Soini has +pointed out that the code in 1.4.4 restricts the length of short zone +names to 4 characters. I've produced version 1.4.4a that restores the +previous 5-character limit by conditionally omitting the log rule number +when the LOGFORMAT doesn't contain '%d'.
    + +

    5/23/2003 - Shorewall-1.4.4

    + I apologize for the rapid-fire releases but since there is +a potential configuration change required to go from 1.4.3a to 1.4.4, + I decided to make it a full release rather than just a bug-fix release. +
    +
    +     Problems corrected:
    + +
    None.
    +
    +     New Features:
    +     +
      +
    1. A REDIRECT- rule target has been added. This target behaves + for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter + nat table REDIRECT rule is added but not the companion filter table +ACCEPT rule.
      +
      +
      2. +
    2. The LOGMARKER variable has been renamed LOGFORMAT and +has been changed to a 'printf' formatting template which accepts three +arguments (the chain name, logging rule number and the disposition). +To use LOGFORMAT with fireparse (http://www.fireparse.com), set it + as:
      +  
      +        LOGFORMAT="fp=%s:%d a=%s "
      +  
      + CAUTION: /sbin/shorewall uses the leading part of + the LOGFORMAT string (up to but not including the first '%') to find + log messages in the 'show log', 'status' and 'hits' commands. This part + should not be omitted (the LOGFORMAT should not begin with "%") and +the leading part should be sufficiently unique for /sbin/shorewall to +identify Shorewall messages.
      +
      +
      3. +
    3. When logging is specified on a DNAT[-] or REDIRECT[-] +rule, the logging now takes place in the nat table rather than in the +filter table. This way, only those connections that actually undergo +DNAT or redirection will be logged.
      +
      4. + +
    + +

    5/20/2003 - Shorewall-1.4.3a
    +

    + This version primarily corrects the documentation included + in the .tgz and in the .rpm. In addition:
    -
+
    +
  1. (This change is in 1.4.3 but is not documented) If +you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall +will return reject replies as follows:
    +    a) tcp - RST
    +    b) udp - ICMP port unreachable
    +    c) icmp - ICMP host unreachable
    +    d) Otherwise - ICMP host prohibited
    + If you are running earlier software, Shorewall will follow + it's traditional convention:
    +    a) tcp - RST
    +    b) Otherwise - ICMP port unreachable
    2. +
  2. UDP port 135 is now silently dropped in the common.def + chain. Remember that this chain is traversed just before a DROP or + REJECT policy is enforced.
    +
    3. + +
+ +

5/18/2003 - Shorewall 1.4.3
+

+     Problems Corrected:
+ +
    +
  1. There were several cases where Shorewall would fail + to remove a temporary directory from /tmp. These cases have been corrected.
    2. +
  2. The rules for allowing all traffic via the loopback + interface have been moved to before the rule that drops status=INVALID + packets. This insures that all loopback traffic is allowed even if +Netfilter connection tracking is confused.
    3. + +
+     New Features:
+ +
    +
  1.  IPV6-IPV4 (6to4) tunnels are now supported in the +/etc/shorewall/tunnels file.
    2. +
  2. You may now change the leading portion of + the --log-prefix used by Shorewall using the LOGMARKER variable in + shorewall.conf. By default, "Shorewall:" is used.
    +
    3. + +
+ +

5/10/2003 - Shorewall Mirror in Asia
+

-

2/8/2003 - Shoreawall 1.3.14

- -

New features include

- +

Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
+

+ +

5/8/2003 - Shorewall Mirror in Chile

+ Thanks to Darcy Ganga, there is now an HTTP mirror + in Santiago Chile. +

4/21/2003 - Samples updated for Shorewall version 1.4.2

+ +

Thanks to Francesca Smith, the sample configurations are now upgraded +to Shorewall version 1.4.2.

+ +

4/9/2003 - Shorewall 1.4.2
+

+ +

    Problems Corrected:

+ +
+ +
    +
  1. TCP connection requests rejected out of the + common chain are now properly rejected with TCP RST; +previously, some of these requests were rejected with an ICMP port-unreachable +response.
    2. +
  2. 'traceroute -I' from behind the firewall previously + timed out on the first hop (e.g., to the firewall). This has been + worked around.
    3. + + +
+
+ +

    New Features:

+
    -
  1. An OLD_PING_HANDLING option has been added - to shorewall.conf. When set to Yes, Shorewall ping handling - is as it has always been (see http://www.shorewall.net/ping.html).
    -
    - When OLD_PING_HANDLING=No, icmp echo (ping) - is handled via rules and policies just like any other connection - request. The FORWARDPING=Yes option in shorewall.conf and -the 'noping' and 'filterping' options in /etc/shorewall/interfaces - will all generate an error.
    -
    -
    2. -
  2. It is now possible to direct Shorewall -to create a "label" such as  "eth0:0" for IP addresses that -it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. -This is done by specifying the label instead of just the interface -name:
    -  
    -    a) In the INTERFACE column of /etc/shorewall/masq
    -    b) In the INTERFACE column of /etc/shorewall/nat
    -  
    3. -
  3. Support for OpenVPN Tunnels.
    -
    -
    4. -
  4. Support for VLAN devices with names of -the form $DEV.$VID (e.g., eth0.0)
    -
    -
    5. -
  5. In /etc/shorewall/tcrules, the MARK value - may be optionally followed by ":" and either 'F' or 'P' to designate - that the marking will occur in the FORWARD or PREROUTING chains -respectively. If this additional specification is omitted, the chain -used to mark packets will be determined by the setting of the MARK_IN_FORWARD_CHAIN - option in shorewall.conf.
    -
    -
    6. -
  6. When an interface name is entered in the - SUBNET column of the /etc/shorewall/masq file, Shorewall previously - masqueraded traffic from only the first subnet defined on that - interface. It did not masquerade traffic from:
    -  
    -    a) The subnets associated with other -addresses on the interface.
    -    b) Subnets accessed through local routers.
    -  
    - Beginning with Shorewall 1.3.14, if you -enter an interface name in the SUBNET column, shorewall will -use the firewall's routing table to construct the masquerading/SNAT -rules.
    -  
    - Example 1 -- This is how it works in 1.3.14.
    -   
    - - - - 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - - - - 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    - - - - 
       [root@gateway test]# shorewall start
       ...
       Masqueraded Subnets and Hosts:
           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
       Processing /etc/shorewall/tos...
    -  
    - When upgrading to Shorewall 1.3.14, if -you have multiple local subnets connected to an interface -that is specified in the SUBNET column of an /etc/shorewall/masq - entry, your /etc/shorewall/masq file will need changing. In -most cases, you will simply be able to remove redundant entries. -In some cases though, you might want to change from using the interface - name to listing specific subnetworks if the change described above -will cause masquerading to occur on subnetworks that you don't wish -to masquerade.
    -  
    - Example 2 -- Suppose that your current -config is as follows:
    -   
    - - - - 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       eth0                    192.168.10.0/24         206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - - - - 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    -  
    -    In this case, the second entry in /etc/shorewall/masq - is no longer required.
    -  
    - Example 3 -- What if your current configuration - is like this?
    -  
    - - - - 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - - - - 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    -  
    -    In this case, you would want to change - the entry in  /etc/shorewall/masq to:
    - - - - 
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    192.168.1.0/24          206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    7. - +
  7. Where an entry in the/etc/shorewall/hosts file + specifies a particular host or network, Shorewall now creates +an intermediate chain for handling input from the related zone. +This can substantially reduce the number of rules traversed by connections + requests from such zones.
    +
    +
    8. +
  8. Any file may include an INCLUDE directive. An +INCLUDE directive consists of the word INCLUDE followed by a file +name and causes the contents of the named file to be logically included +into the file containing the INCLUDE. File names given in an INCLUDE +directive are assumed to reside in /etc/shorewall or in an alternate +configuration directory if one has been specified for the command. +
    +  
    +    Examples:
    +    shorewall/params.mgmt:
    +    MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
    +    TIME_SERVERS=4.4.4.4
    +    BACKUP_SERVERS=5.5.5.5
    +    ----- end params.mgmt -----
    +  
    +  
    +    shorewall/params:
    +    # Shorewall 1.3 /etc/shorewall/params
    +    [..]
    +    #######################################
    +  
    +    INCLUDE params.mgmt   
    +  
    +    # params unique to this host here
    +    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - +DO NOT REMOVE
    +    ----- end params -----
    +  
    +  
    +    shorewall/rules.mgmt:
    +    ACCEPT net:$MGMT_SERVERS          $FW    tcp    + 22
    +    ACCEPT $FW          net:$TIME_SERVERS    udp    + 123
    +    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    + 22
    +    ----- end rules.mgmt -----
    +  
    +    shorewall/rules:
    +    # Shorewall version 1.3 - Rules File
    +    [..]
    +    #######################################
    +  
    +    INCLUDE rules.mgmt    
    +  
    +    # rules unique to this host here
    +    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE +-- DO NOT REMOVE
    +    ----- end rules -----
    +  
    + INCLUDE's may be nested to a level of 3 -- further + nested INCLUDE directives are ignored with a warning message.
    +
    +
    9. +
  9. Routing traffic from an interface back out that + interface continues to be a problem. While I firmly believe that + this should never happen, people continue to want to do it. To limit + the damage that such nonsense produces, I have added a new 'routeback' + option in /etc/shorewall/interfaces and /etc/shorewall/hosts. When +used in /etc/shorewall/interfaces, the 'ZONE' column may not contain + '-'; in other words, 'routeback' can't be used as an option for a multi-zone + interface. The 'routeback' option CAN be specified however on individual + group entries in /etc/shorewall/hosts.
    +  
    + The 'routeback' option is similar to the old 'multi' + option with two exceptions:
    +  
    +    a) The option pertains to a particular zone,interface,address + tuple.
    +  
    +    b) The option only created infrastructure to pass + traffic from (zone,interface,address) tuples back to themselves + (the 'multi' option affected all (zone,interface,address) tuples + associated with the given 'interface').
    +  
    + See the 'Upgrade Issues' + for information about how this new option may affect your configuration.
    +
    10. +
- -


- 2/5/2003 - Shorewall Support included in -Webmin 1.060

+ +

3/24/2003 - Shorewall 1.4.1

+ + + + + + + + + + + + + + + + + + + + + +

This release follows up on 1.4.0. It corrects a problem introduced in 1.4.0 +and removes additional warts.
+
+ Problems Corrected:
+

+ +
    +
  1. When Shorewall 1.4.0 is run under the ash shell + (such as on Bering/LEAF), it can attempt to add ECN disabling +rules even if the /etc/shorewall/ecn file is empty. That problem +has been corrected so that ECN disabling rules are only added if +there are entries in /etc/shorewall/ecn.
    2. + +
+ New Features:
+ +
Note: In the list that follows, the term group refers +to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be +a host address) accessed through a particular interface. Examples:
+ + +
eth0:0.0.0.0/0
+ eth2:192.168.1.0/24
+ eth3:192.0.2.123
+
+ You can use the "shorewall check" command to see +the groups associated with each of your zones.
+
+ +
    +
  1. Beginning with Shorewall 1.4.1, if a zone Z +comprises more than one group then if there is no explicit +Z to Z policy and there are no rules governing traffic from Z to +Z then Shorewall will permit all traffic between the groups in the +zone.
    2. +
  2. Beginning with Shorewall 1.4.1, Shorewall will + never create rules to handle traffic from a group to itself.
    3. +
  3. A NONE policy is introduced in 1.4.1. When a +policy of NONE is specified from Z1 to Z2:
    4. + +
+ +
    +
  • There may be no rules created that govern connections + from Z1 to Z2.
    • +
  • Shorewall will not create any infrastructure +to handle traffic from Z1 to Z2.
    • + +
+ See the upgrade issues + for a discussion of how these changes may affect your configuration. + +

3/17/2003 - Shorewall 1.4.0

+ +Shorewall 1.4 represents the next step in the evolution of +Shorewall. The main thrust of the initial release is simply to +remove the cruft that has accumulated in Shorewall over time.
+
+ IMPORTANT: Shorewall 1.4.0 requires the + iproute package ('ip' utility).
+
+ Function from 1.3 that has been omitted +from this version include:
+ +
    +
  1. The MERGE_HOSTS variable in shorewall.conf + is no longer supported. Shorewall 1.4 behavior is the same as +1.3 with MERGE_HOSTS=Yes.
    +
    +
    2. +
  2. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
    +
    +
    3. +
  3. Shorewall 1.4 implements behavior consistent + with OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate + an error at startup as will specification of the 'noping' +or 'filterping' interface options.
    +
    +
    4. +
  4. The 'routestopped' option in the /etc/shorewall/interfaces + and /etc/shorewall/hosts files is no longer supported and +will generate an error at startup if specified.
    +
    +
    5. +
  5. The Shorewall 1.2 syntax for DNAT and + REDIRECT rules is no longer accepted.
    +
    +
    6. +
  6. The ALLOWRELATED variable in shorewall.conf + is no longer supported. Shorewall 1.4 behavior is the same as + 1.3 with ALLOWRELATED=Yes.
    +
    +
    7. +
  7. The icmp.def file has been removed.
    +
    8. + +
+ Changes for 1.4 include:
+ +
    +
  1. The /etc/shorewall/shorewall.conf file + has been completely reorganized into logical sections.
    +
    +
    2. +
  2. LOG is now a valid action for a rule + (/etc/shorewall/rules).
    +
    +
    3. +
  3. The firewall script and version file + are now installed in /usr/share/shorewall.
    +
    +
    4. +
  4. Late arriving DNS replies are now silently + dropped in the common chain by default.
    +
    +
    5. +
  5. In addition to behaving like OLD_PING_HANDLING=No, + Shorewall 1.4 no longer unconditionally accepts outbound +ICMP packets. So if you want to 'ping' from the firewall, you +will need the appropriate rule or policy.
    +
    +
    6. +
  6. CONTINUE is now a valid action for a rule +(/etc/shorewall/rules).
    +
    +
    7. +
  7. 802.11b devices with names of the form wlan<n> + now support the 'maclist' option.
    +
    +
    8. +
  8. Explicit Congestion Notification (ECN - RFC + 3168) may now be turned off on a host or network basis using the + new /etc/shorewall/ecn file. To use this facility:
    +
    +    a) You must be running kernel 2.4.20
    +    b) You must have applied the patch in
    +    http://www.shorewall/net/pub/shorewall/ecn/patch.
    +    c) You must have iptables 1.2.7a installed.
    +
    +
    9. +
  9. The /etc/shorewall/params file is now processed + first so that variables may be used in the /etc/shorewall/shorewall.conf + file.
    +
    +
    10. +
  10. Shorewall now gives a more helpful + diagnostic when the 'ipchains' compatibility kernel module is +loaded and a 'shorewall start' command is issued.
    +
    +
    11. +
  11. The SHARED_DIR variable has been removed from + shorewall.conf. This variable was for use by package maintainers + and was not documented for general use.
    +
    +
    12. +
  12. Shorewall now ignores 'default' routes when + detecting masq'd networks.
    13. + +
+ +

3/10/2003 - Shoreall 1.3.14a

+ +

A roleup of the following bug fixes and other updates:

+ +
    +
  • There is an updated rfc1918 file that reflects + the resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • + +
-

Webmin version 1.060 now has Shorewall support included as standard. See - http://www.webmin.com.
-
- 2/4/2003 - Shorewall 1.3.14-RC1

- -

Includes the Beta 2 content plus support for OpenVPN tunnels.

- -

1/28/2003 - Shorewall 1.3.14-Beta2

- -

Includes the Beta 1 content plus restores VLAN device names of the form - $dev.$vid (e.g., eth0.1)

- -

1/25/2003 - Shorewall 1.3.14-Beta1
-

- -

The Beta includes the following changes:
-

- +
    +
  • The documentation for the routestopped file +claimed that a comma-separated list could appear in the second +column while the code only supported a single host or network address.
    • +
  • Log messages produced by 'logunclean' and 'dropunclean' + were not rate-limited.
    • +
  • 802.11b devices with names of the form wlan<n> + don't support the 'maclist' interface option.
    • +
  • Log messages generated by RFC 1918 filtering + are not rate limited.
    • +
  • The firewall fails to start in the case where + you have "eth0 eth1" in /etc/shorewall/masq and the default route + is through eth1
    • + +
+ +

2/8/2003 - Shoreawall 1.3.14

+ +

New features include

+
    -
  1. An OLD_PING_HANDLING option has been - added to shorewall.conf. When set to Yes, Shorewall ping -handling is as it has always been (see http://www.shorewall.net/ping.html).
    -
    - When OLD_PING_HANDLING=No, icmp echo (ping) - is handled via rules and policies just like any other connection - request. The FORWARDPING=Yes option in shorewall.conf and -the 'noping' and 'filterping' options in /etc/shorewall/interfaces - will all generate an error.
    +
  2. An OLD_PING_HANDLING option has +been added to shorewall.conf. When set to Yes, Shorewall +ping handling is as it has always been (see http://www.shorewall.net/ping.html).
    +
    + When OLD_PING_HANDLING=No, icmp +echo (ping) is handled via rules and policies just like +any other connection request. The FORWARDPING=Yes option +in shorewall.conf and the 'noping' and 'filterping' options in + /etc/shorewall/interfaces will all generate an error.
    +
    +
    3. +
  3. It is now possible to direct Shorewall + to create a "label" such as  "eth0:0" for IP addresses +that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. + This is done by specifying the label instead of just the interface + name:
    +  
    +    a) In the INTERFACE column of +/etc/shorewall/masq
    +    b) In the INTERFACE column of +/etc/shorewall/nat
    +  
    4. +
  4. Support for OpenVPN Tunnels.
    +
    +
    5. +
  5. Support for VLAN devices with names + of the form $DEV.$VID (e.g., eth0.0)

    6. -
  6. It is now possible to direct Shorewall - to create a "label" such as  "eth0:0" for IP addresses that - it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. - This is done by specifying the label instead of just the interface - name:
    -  
    -    a) In the INTERFACE column of /etc/shorewall/masq
    -    b) In the INTERFACE column of /etc/shorewall/nat
    -  
    7. -
  7. When an interface name is entered -in the SUBNET column of the /etc/shorewall/masq file, Shorewall - previously masqueraded traffic from only the first subnet -defined on that interface. It did not masquerade traffic from:
    -  
    -    a) The subnets associated with other -addresses on the interface.
    -    b) Subnets accessed through local routers.
    -  
    - Beginning with Shorewall 1.3.14, if you -enter an interface name in the SUBNET column, shorewall will -use the firewall's routing table to construct the masquerading/SNAT -rules.
    -  
    - Example 1 -- This is how it works in 1.3.14.
    -   
    +
  8. In /etc/shorewall/tcrules, the MARK + value may be optionally followed by ":" and either 'F' or 'P' + to designate that the marking will occur in the FORWARD or PREROUTING + chains respectively. If this additional specification is omitted, + the chain used to mark packets will be determined by the setting + of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
    +
    +
    9. +
  9. When an interface name is entered + in the SUBNET column of the /etc/shorewall/masq file, Shorewall + previously masqueraded traffic from only the first subnet + defined on that interface. It did not masquerade traffic from:
    +  
    +    a) The subnets associated with + other addresses on the interface.
    +    b) Subnets accessed through local + routers.
    +  
    + Beginning with Shorewall 1.3.14, +if you enter an interface name in the SUBNET column, shorewall + will use the firewall's routing table to construct the masquerading/SNAT + rules.
    +  
    + Example 1 -- This is how it works + in 1.3.14.
    +   
    - + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    - + + 
       [root@gateway test]# shorewall start
       ...
       Masqueraded Subnets and Hosts:
           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
       Processing /etc/shorewall/tos...
    -  
    - When upgrading to Shorewall 1.3.14, if -you have multiple local subnets connected to an interface -that is specified in the SUBNET column of an /etc/shorewall/masq - entry, your /etc/shorewall/masq file will need changing. In -most cases, you will simply be able to remove redundant entries. -In some cases though, you might want to change from using the interface - name to listing specific subnetworks if the change described above -will cause masquerading to occur on subnetworks that you don't wish +  
    + When upgrading to Shorewall 1.3.14, + if you have multiple local subnets connected to an interface + that is specified in the SUBNET column of an /etc/shorewall/masq + entry, your /etc/shorewall/masq file will need changing. In + most cases, you will simply be able to remove redundant entries. + In some cases though, you might want to change from using the interface + name to listing specific subnetworks if the change described above + will cause masquerading to occur on subnetworks that you don't wish to masquerade.
    -  
    - Example 2 -- Suppose that your current -config is as follows:
    -   
    +  
    + Example 2 -- Suppose that your current + config is as follows:
    +   
    - + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       eth0                    192.168.10.0/24         206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    -  
    -    In this case, the second entry in /etc/shorewall/masq - is no longer required.
    -  
    - Example 3 -- What if your current configuration - is like this?
    -  
    +  
    +    In this case, the second entry + in /etc/shorewall/masq is no longer required.
    +  
    + Example 3 -- What if your current + configuration is like this?
    +  
    - + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    -  
    -    In this case, you would want to change - the entry in  /etc/shorewall/masq to:
    +  
    +    In this case, you would want +to change the entry in  /etc/shorewall/masq to:
    - + + 
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    192.168.1.0/24          206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    10. - + +
- -

1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format

- - -

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

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

1/17/2003 - shorewall.net has MOVED 

+ +


+ 2/5/2003 - Shorewall Support included + in Webmin 1.060

+ +

Webmin version 1.060 now has Shorewall support included as standard. See + http://www.webmin.com.
+
+ 2/4/2003 - Shorewall 1.3.14-RC1

-

Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net and ftp.shorewall.net -are now hosted on a system in Bellevue, Washington. A big thanks to Alex -for making this happen.
-

+

Includes the Beta 2 content plus support for OpenVPN tunnels.

-

1/13/2003 - Shorewall 1.3.13
-

- - -

Just includes a few things that I had on the burner:
-

- - -
    -
  1. A new 'DNAT-' action has been -added for entries in the /etc/shorewall/rules file. DNAT- -is intended for advanced users who wish to minimize the number - of rules that connection requests must traverse.
    -
    - A Shorewall DNAT rule actually generates - two iptables rules: a header rewriting rule in the 'nat' -table and an ACCEPT rule in the 'filter' table. A DNAT- rule -only generates the first of these rules. This is handy when you -have several DNAT rules that would generate the same ACCEPT rule.
    -
    -    Here are three rules from my previous - rules file:
    -
    -         DNAT   net  dmz:206.124.146.177 - tcp smtp - 206.124.146.178
    -         DNAT   net  dmz:206.124.146.177 - tcp smtp - 206.124.146.179
    -         ACCEPT net  dmz:206.124.146.177 - tcp www,smtp,ftp,...
    -
    -    These three rules ended up generating - _three_ copies of
    -
    -          ACCEPT net  dmz:206.124.146.177 - tcp smtp
    -
    -    By writing the rules this way, I -end up with only one copy of the ACCEPT rule.
    -
    -         DNAT-  net  dmz:206.124.146.177 - tcp smtp -  206.124.146.178
    -         DNAT-  net  dmz:206.124.146.177 - tcp smtp -  206.124.146.179
    -         ACCEPT net  dmz:206.124.146.177 - tcp www,smtp,ftp,....
    -
    -
    2. -
  2. The 'shorewall check' command -now prints out the applicable policy between each pair of -zones.
    -
    -
    3. -
  3. A new CLEAR_TC option has been - added to shorewall.conf. If this option is set to 'No' then - Shorewall won't clear the current traffic control rules during - [re]start. This setting is intended for use by people that prefer - to configure traffic shaping when the network interfaces come up -rather than when the firewall is started. If that is what you want -to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart - file. That way, your traffic shaping rules can still use the 'fwmark' - classifier based on packet marking defined in /etc/shorewall/tcrules.
    -
    -
    4. -
  4. A new SHARED_DIR variable has -been added that allows distribution packagers to easily move -the shared directory (default /usr/lib/shorewall). Users should - never have a need to change the value of this shorewall.conf - setting.
    -
    5. - - -
- - -

1/6/2003 - BURNOUT -

+

1/28/2003 - Shorewall 1.3.14-Beta2

-

Until further notice, I will not be involved in either Shorewall Development - or Shorewall Support

+

Includes the Beta 1 content plus restores VLAN device names of the form + $dev.$vid (e.g., eth0.1)

-

-Tom Eastep
+

1/25/2003 - Shorewall 1.3.14-Beta1

- + +

The Beta includes the following changes:
+

+ + +
    +
  1. An OLD_PING_HANDLING option + has been added to shorewall.conf. When set to Yes, Shorewall + ping handling is as it has always been (see http://www.shorewall.net/ping.html).
    +
    + When OLD_PING_HANDLING=No, icmp +echo (ping) is handled via rules and policies just like +any other connection request. The FORWARDPING=Yes option +in shorewall.conf and the 'noping' and 'filterping' options in + /etc/shorewall/interfaces will all generate an error.
    +
    +
    2. +
  2. It is now possible to direct + Shorewall to create a "label" such as  "eth0:0" for IP addresses + that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. + This is done by specifying the label instead of just the interface + name:
    +  
    +    a) In the INTERFACE column of +/etc/shorewall/masq
    +    b) In the INTERFACE column of +/etc/shorewall/nat
    +  
    3. +
  3. When an interface name is +entered in the SUBNET column of the /etc/shorewall/masq + file, Shorewall previously masqueraded traffic from only +the first subnet defined on that interface. It did not masquerade + traffic from:
    +  
    +    a) The subnets associated with + other addresses on the interface.
    +    b) Subnets accessed through local + routers.
    +  
    + Beginning with Shorewall 1.3.14, +if you enter an interface name in the SUBNET column, shorewall + will use the firewall's routing table to construct the masquerading/SNAT + rules.
    +  
    + Example 1 -- This is how it works + in 1.3.14.
    +   
    + + + + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + + + + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    + + + + + 
       [root@gateway test]# shorewall start
       ...
       Masqueraded Subnets and Hosts:
           To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
           To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
       Processing /etc/shorewall/tos...
    +  
    + When upgrading to Shorewall 1.3.14, + if you have multiple local subnets connected to an interface + that is specified in the SUBNET column of an /etc/shorewall/masq + entry, your /etc/shorewall/masq file will need changing. In + most cases, you will simply be able to remove redundant entries. + In some cases though, you might want to change from using the interface + name to listing specific subnetworks if the change described above + will cause masquerading to occur on subnetworks that you don't wish +to masquerade.
    +  
    + Example 2 -- Suppose that your current + config is as follows:
    +   
    + + + + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       eth0                    192.168.10.0/24         206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + + + + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    +  
    +    In this case, the second entry + in /etc/shorewall/masq is no longer required.
    +  
    + Example 3 -- What if your current + configuration is like this?
    +  
    + + + + + 
       [root@gateway test]# cat /etc/shorewall/masq
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    eth2                    206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + + + + + 
       [root@gateway test]# ip route show dev eth2
       192.168.1.0/24  scope link
       192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
       [root@gateway test]#
    +  
    +    In this case, you would want +to change the entry in  /etc/shorewall/masq to:
    + + + + + 
       #INTERFACE              SUBNET                  ADDRESS
       eth0                    192.168.1.0/24          206.124.146.176
       #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    +
    4. + + +
+ + +

1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format

+ + +

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

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

1/17/2003 - shorewall.net has MOVED 

+ + +

Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net and +ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A +big thanks to Alex for making this happen.
+

+ + +

1/13/2003 - Shorewall 1.3.13
+

+ + +

Just includes a few things that I had on the burner:
+

+ + +
    +
  1. A new 'DNAT-' action has + been added for entries in the /etc/shorewall/rules file. + DNAT- is intended for advanced users who wish to minimize the + number of rules that connection requests must traverse.
    +
    + A Shorewall DNAT rule actually + generates two iptables rules: a header rewriting rule +in the 'nat' table and an ACCEPT rule in the 'filter' table. + A DNAT- rule only generates the first of these rules. This +is handy when you have several DNAT rules that would generate the + same ACCEPT rule.
    +
    +    Here are three rules from +my previous rules file:
    +
    +         DNAT   net  dmz:206.124.146.177 + tcp smtp - 206.124.146.178
    +         DNAT   net  dmz:206.124.146.177 + tcp smtp - 206.124.146.179
    +         ACCEPT net  dmz:206.124.146.177 + tcp www,smtp,ftp,...
    +
    +    These three rules ended up + generating _three_ copies of
    +
    +          ACCEPT net  dmz:206.124.146.177 + tcp smtp
    +
    +    By writing the rules this +way, I end up with only one copy of the ACCEPT rule.
    +
    +         DNAT-  net  dmz:206.124.146.177 + tcp smtp -  206.124.146.178
    +         DNAT-  net  dmz:206.124.146.177 + tcp smtp -  206.124.146.179
    +         ACCEPT net  dmz:206.124.146.177 + tcp www,smtp,ftp,....
    +
    +
    2. +
  2. The 'shorewall check' +command now prints out the applicable policy between +each pair of zones.
    +
    +
    3. +
  3. A new CLEAR_TC option +has been added to shorewall.conf. If this option is set +to 'No' then Shorewall won't clear the current traffic control + rules during [re]start. This setting is intended for use by +people that prefer to configure traffic shaping when the network + interfaces come up rather than when the firewall is started. If +that is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No +and do not supply an /etc/shorewall/tcstart file. That way, your +traffic shaping rules can still use the 'fwmark' classifier based +on packet marking defined in /etc/shorewall/tcrules.
    +
    +
    4. +
  4. A new SHARED_DIR variable + has been added that allows distribution packagers to +easily move the shared directory (default /usr/lib/shorewall). + Users should never have a need to change the value of this +shorewall.conf setting.
    +
    5. + + +
+ + +

1/6/2003 - BURNOUT +

+ + +

Until further notice, I will not be involved in either Shorewall Development + or Shorewall Support

+ + +

-Tom Eastep
+

+ +

12/30/2002 - Shorewall Documentation in PDF Format

- -

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

+ +

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

- +

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

+

- +

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 "shorewall refresh" +now reloads the traffic shaping rules (tcrules and +tcstart).
    6. +
  6. "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.
    7. +
  7. "shorewall [re]start" + has been speeded up by more than 40% with my configuration. + Your milage may vary.
    8. +
  8. 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"
    9. +
  9. 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.
    10. -
  10. 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.
    11. -
  11. 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.
    12. -
  12. 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.
    -
    13. +
  13. 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.
    14. +
  14. 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.
    15. +
  15. 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.
    +
    16. - +
- +

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

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

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 "shorewall refresh" + now reloads the traffic shaping rules (tcrules +and tcstart).
    6. +
  6. "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.
    7. +
  7. "shorewall [re]start" + has been speeded up by more than 40% with my configuration. + Your milage may vary.
    8. +
  8. 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"
    9. +
  9. 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.
    10. -
  10. 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.
    11. -
  11. 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.
    12. +
  12. 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.
    13. +
  13. 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.
    14. - +
- You may download the Beta from:
+ 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.
+

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

- - -

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

    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.

    -
- You may download - the Beta from:
+

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

+ + + +

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

- - - -

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

12/3/2002 - Shorewall 1.3.11a

-

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

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.

-
- 9/30/2002 - Shorewall - 1.3.9a

- Roles up the -fix for broken tunnels.
+ +

11/24/2002 - Shorewall 1.3.11

- -

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

In this version:

- -

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.
    -
    • +
  • 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/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability - Restored
+ +

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

-Brown Paper Bag - A couple - of recent configuration changes at www.shorewall.net - broke the Search facility:
+ +

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

+ + +

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

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

    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:

-
- 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:
    • +
  • 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
    • - - - -
      - -
    • There is a policy for za to zb; or -
      • - -
    • There is at least one rule for za to zb.
      • - - - - -
    - - +
+ +

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

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 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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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
    • +
  • Shorewall now works with iptables 1.2.7
    • -
  • The documentation and web site no longer uses - FrontPage themes.
    • +
  • 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.

+ +

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

+ +

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.

+ +

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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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 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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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.
    • +
  • 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 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 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.
    • +
  • 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.
    • +
  • Ignore robot.txt files.
    • -
  • Recursively copy everything that they find.
    • +
  • Recursively copy everything that they find.
    • -
  • Should be classified as weapons rather than tools.
    • +
  • 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.

+ + +

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

+ +

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:

- +
    -
  • Corrects a serious problem with "all <zone> - CONTINUE" policies. This problem is present in all - versions of Shorewall that support the CONTINUE - policy. These previous versions optimized away the "all2<zone>" - chain and replaced it with the "all2all" chain with -the usual result that a policy of REJECT was enforced rather - than the intended CONTINUE policy.
    • +
  • Corrects a serious problem with "all + <zone> CONTINUE" policies. This + problem is present in all versions of Shorewall that + support the CONTINUE policy. These previous versions + optimized away the "all2<zone>" chain +and replaced it with the "all2all" chain with the usual result +that a policy of REJECT was enforced rather than the intended + CONTINUE policy.
    • -
  • Adds an /etc/shorewall/rfc1918 - file for defining the exact behavior of theAdds an /etc/shorewall/rfc1918 + file for defining the exact behavior of the 'norfc1918' interface option.
    • - + +
- + +

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:

- +
    -
  • Support for the /etc/shorewall/whitelist file - has been withdrawn. If you need whitelisting, see - these instructions.
    • +
  • Support for the /etc/shorewall/whitelist + file has been withdrawn. If you need whitelisting, + see these + instructions.
    • - + +
- +

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

+ +

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
    • +
  • The 'try' command works again
    • -
  • There is now a single RPM that also works with - SuSE.
    • +
  • 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.

+ +

Thanks to Stefan Mohr, there + is now a Shorewall 1.2.11 + SuSE RPM available.

- +

4/13/2002 - Shorewall 1.2.11 Available

- +

In this version:

- +
    -
  • The 'try' command now accepts an optional timeout. - If the timeout is given in the command, the standard - configuration will automatically be restarted after - the new configuration has been running for that length -of time. This prevents a remote admin from being locked -out of the firewall in the case where the new configuration - starts but prevents access.
    • +
  • The 'try' command now accepts an optional + timeout. If the timeout is given in the command, + the standard configuration will automatically be + restarted after the new configuration has been running + for that length of time. This prevents a remote admin + from being locked out of the firewall in the case where + the new configuration starts but prevents access.
    • -
  • Kernel route filtering may now be enabled globally - using the new ROUTE_FILTER parameter in /etc/shorewall/shorewall.conf.
    • +
  • Kernel route filtering may now be enabled + globally using the new ROUTE_FILTER parameter + in /etc/shorewall/shorewall.conf.
    • -
  • Individual IP source addresses and/or subnets - may now be excluded from masquerading/SNAT.
    • +
  • Individual IP source addresses and/or subnets + may now be excluded from masquerading/SNAT.
    • -
  • Simple "Yes/No" and "On/Off" values are now -case-insensitive in /etc/shorewall/shorewall.conf.
    • +
  • Simple "Yes/No" and "On/Off" values are + now case-insensitive in /etc/shorewall/shorewall.conf.
    • - + +
- +

4/13/2002 - Hamburg Mirror now has FTP

- +

Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.  - Thanks Stefan!

+ href="ftp://germany.shorewall.net/pub/shorewall"> ftp://germany.shorewall.net/pub/shorewall.  + 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. -

+ +

Thanks to Stefan Mohr, there + 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.

+ +

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.

- +

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.

+ +

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.

- +

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.

+ href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">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.

- +

4/2/2002 - Updated Log Parser

- -

John Lodge has provided an updated - version of his CGI-based log parser - with corrected date handling.

+ +

John Lodge has provided an updated + 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 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.

- +

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.

+ href="pub/shorewall/parsefw/">CGI-based log parser for Shorewall. Thanks + John.

- +

3/20/2002 - Shorewall 1.2.10 Released

- +

In this version:

- +
    -
  • A "shorewall try" command has been added (syntax: - shorewall try <configuration directory>). - This command attempts "shorewall -c <configuration - directory> start" and if that results in the - firewall being stopped due to an error, a "shorewall start" - command is executed. The 'try' command allows you to -create a new configuration - and attempt to start it; if there is an error that leaves - your firewall in the stopped state, it will automatically - be restarted using the default configuration (in /etc/shorewall).
    • +
  • A "shorewall try" command has been added + (syntax: shorewall try <configuration + directory>). This command attempts "shorewall + -c <configuration directory> start" + and if that results in the firewall being stopped due + to an error, a "shorewall start" command is executed. + The 'try' command allows you to create a new configuration and attempt + to start it; if there is an error that leaves your +firewall in the stopped state, it will automatically be restarted + using the default configuration (in /etc/shorewall).
    • -
  • A new variable ADD_SNAT_ALIASES has been added - to /etc/shorewall/shorewall.conf. - If this variable is set to "Yes", Shorewall will - automatically add IP addresses listed in the -third column of the /etc/shorewall/masq - file.
    • +
  • A new variable ADD_SNAT_ALIASES has been + added to /etc/shorewall/shorewall.conf. + If this variable is set to "Yes", Shorewall + will automatically add IP addresses listed + in the third column of the + /etc/shorewall/masq file.
    • -
  • Copyright notices have been added to the documenation.
    • +
  • Copyright notices have been added to the + documenation.
    • - + +
- + +

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

- + +

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

+ + +

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.

+ +

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.

- +

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

+ +

Due to installation problems with Shorewall 1.2.4, I have released Shorewall + 1.2.5. Sorry for the rapid-fire development.

- +

In version 1.2.5:

- +
    -
  • The installation problems have been corrected.
    • +
  • The installation problems have been corrected.
    • -
  • SNAT is now supported.
    • +
  • SNAT is now supported.
    • -
  • A "shorewall version" command has been added
    • +
  • 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 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.
    • +
  • 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
    • +
  • 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".
    • +
  • 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.
    • +
  • "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.

+ +

Corrects a problem with BLACKLIST_LOGLEVEL. See the + errata for details.

- +

1/19/2002 - Shorewall 1.2.3 Released

- +

This is a minor feature and bugfix release. The single new feature is:

- +
    -
  • Support for TCP MSS Clamp to PMTU -- This support - is usually required when the internet connection - is via PPPoE or PPTP and may be enabled using the - CLAMPMSS option in - /etc/shorewall/shorewall.conf.
    • +
  • Support for TCP MSS Clamp to PMTU -- This + support is usually required when the internet + connection is via PPPoE or PPTP and may be enabled + using the CLAMPMSS + option in /etc/shorewall/shorewall.conf.
    • - + +
- + +

The following problems were corrected:

- + +
    -
  • The "shorewall status" command no longer hangs.
    • +
  • The "shorewall status" command no longer + hangs.
    • -
  • The "shorewall monitor" command now displays - the icmpdef chain
    • +
  • The "shorewall monitor" command now displays + the icmpdef chain
    • -
  • The CLIENT PORT(S) column in tcrules is no longer - ignored
    • +
  • 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.

+ +

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.

- +

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.

+ href="mailto:lorenzo.martignoni@milug.org">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.

- +

1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version restores - the "shorewall status" command to health.

+ href="/pub/shorewall/errata/1.2.2/shorewall">This corrected version restores + 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 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 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 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.
      • +
    • 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.
      • +
    • The black list is refreshed from /etc/shorewall/blacklist + by the "shorewall refresh" command.
      • - -
    - -
    • - -
  • 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.
      • - - - - - - -
    - -
    • - -
  • 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:

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

    + + + +
      + +
    • 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 see these instructions. - If you would like to subscribe to the new - list, visit The Shorewall mailing list hosted at + Sourceforge 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

    + + +

    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:

    + +

    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.

    - -
    - - -

    rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

    -
    + +

    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:

    + + + +
    -

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

    + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample +Configurations has been released. In this version:

    - +
      -
    • Ping is now allowed between the zones.
      • +
    • 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. 
      • +
    • 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 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 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 /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 http://www.nrg.sk/mirror/shorewall - and the FTP site is mirrored at 11/19/2001 - Thanks to Juraj + Ontkanin, 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:

    + +

    11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. + There are three sample configurations:

    - +
      -
    • One Interface -- for a standalone system.
      • +
    • One Interface -- for a standalone system.
      • -
    • Two Interfaces -- A masquerading firewall.
      • +
    • Two Interfaces -- A masquerading firewall.
      • -
    • Three Interfaces -- A masquerading firewall with - DMZ.
      • +
    • 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.

    + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17"> ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 + . 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.

    + +

    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.

    - +

    In this version:

    - + - -

    10/22/2001 - The current version of Shorewall is 1.1.16. In this - version:

    + +

    10/22/2001 - The current version of Shorewall is 1.1.16. In this + version:

    - + +
      -
    • A new "shorewall show connections" command has - been added.
      • +
    • A new "shorewall show connections" command + has been added.
      • -
    • In the "shorewall monitor" output, the currently - tracked connections are now shown on a separate - page.
      • +
    • In the "shorewall monitor" output, the currently + tracked connections are now shown on a separate + page.
      • -
    • Prior to this release, Shorewall unconditionally - added the external IP adddress(es) specified in -/etc/shorewall/nat. Beginning with version 1.1.16, - a new parameter (ADD_IP_ALIASES) - may be set to "no" (or "No") to inhibit -this behavior. This allows IP aliases created using -your distribution's network configuration tools - to be used in static NAT. 
      • +
    • Prior to this release, Shorewall unconditionally + added the external IP adddress(es) specified + in /etc/shorewall/nat. Beginning with version + 1.1.16, a new parameter (ADD_IP_ALIASES) + may be set to "no" (or "No") to inhibit + this behavior. This allows IP aliases created +using your distribution's network configuration + tools to be used in static NAT. 
      • - + +
    - -

    10/15/2001 - The current version of Shorewall is 1.1.15. In this - version:

    + +

    10/15/2001 - The current version of Shorewall is 1.1.15. In this + version:

    - + +
      -
    • Support for nested zones has been improved. -See the documentation - for details
      • +
    • Support for nested zones has been improved. + See the documentation + for details
      • -
    • Shorewall now correctly checks the alternate - configuration directory for the 'zones' file.
      • +
    • 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

    - + +

    10/4/2001 - The current version of Shorewall is 1.1.14. In this + version

    + + +
      -
    • Shorewall now supports alternate configuration - directories. When an alternate directory is specified -when starting or restarting Shorewall (e.g., - "shorewall -c /etc/testconf restart"), Shorewall will -first look for configuration files in the alternate directory - then in /etc/shorewall. To create an alternate configuration - simply:
      +
    • Shorewall now supports alternate configuration + directories. When an alternate directory is + specified when starting or restarting Shorewall + (e.g., "shorewall -c /etc/testconf restart"), Shorewall + will first look for configuration files in the alternate + directory then in /etc/shorewall. To create an +alternate configuration simply:
      - 1. Create a New Directory
      + 1. Create a New Directory
      - 2. Copy to that directory any of your configuration - files that you want to change.
      + 2. Copy to that directory any of your configuration + files that you want to change.
      - 3. Modify the copied files as needed.
      + 3. Modify the copied files as needed.
      - 4. Restart Shorewall specifying the new directory.
      • + 4. Restart Shorewall specifying the new directory. -
    • The rules for allowing/disallowing icmp echo-requests - (pings) are now moved after rules created when -processing the rules file. This allows you to add -rules that selectively allow/deny ping based on source or - destination address.
      • +
    • The rules for allowing/disallowing icmp + echo-requests (pings) are now moved after rules + created when processing the rules file. This allows + you to add rules that selectively allow/deny ping based + on source or destination address.
      • -
    • Rules that specify multiple client ip addresses - or subnets no longer cause startup failures.
      • +
    • Rules that specify multiple client ip addresses + or subnets no longer cause startup failures.
      • -
    • Zone names in the policy file are now validated - against the zones file.
      • +
    • Zone names in the policy file are now validated + against the zones file.
      • -
    • If you have packet - mangling support enabled, the "norfc1918" -interface option now logs and drops any incoming packets on -the interface that have an RFC 1918 destination address.
      • +
    • If you have packet mangling + support enabled, the "norfc1918" interface +option now logs and drops any incoming packets on the interface + that have an RFC 1918 destination address.
      • - + +
    - -

    9/12/2001 - The current version of Shorewall is 1.1.13. In this - version

    - + +

    9/12/2001 - The current version of Shorewall is 1.1.13. In this + version

    + + +
      -
    • Shell variables can now be used to parameterize - Shorewall rules.
      • +
    • Shell variables can now be used to parameterize + Shorewall rules.
      • -
    • The second column in the hosts file may now contain - a comma-separated list.
      +
    • The second column in the hosts file may +now contain a comma-separated list.
      -
      +
      - Example:
      + Example:
      -     sea    eth0:130.252.100.0/24,206.191.149.0/24
      • +     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.
      • +
    • 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

    - + +

    8/28/2001 - The current version of Shorewall is 1.1.12. In this + version

    + + +
      -
    • Several columns in the rules file may now contain - comma-separated lists.
      • +
    • 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.
      • +
    • Shorewall is now more rigorous in parsing + the options in /etc/shorewall/interfaces.
      • -
    • Complementation using "!" is now supported in - rules.
      • +
    • Complementation using "!" is now supported + in rules.
      • - + +
    - -

    7/28/2001 - The current version of Shorewall is 1.1.11. In this - version

    - + +

    7/28/2001 - The current version of Shorewall is 1.1.11. In this + 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.
      • +
    • 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 /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 "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" 
      • +
    • 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

    - + +

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

    - + +

    6/23/2001 - The current version of Shorewall is 1.1.9. In this version

    + + +
      -
    • The "tunnels" file really is in the - RPM now.
      • +
    • The "tunnels" file really is in + the RPM now.
      • -
    • SNAT can now be applied to port-forwarded connections.
      • +
    • SNAT can now be applied to port-forwarded + connections.
      • -
    • A bug which would cause firewall start failures - in some dhcp configurations has been fixed.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • Thanks to Alex  Polishchuk, the "hits" command + from seawall is now in shorewall.
      • -
    • Support for IPIP tunnels - has been added.
      • +
    • Support for IPIP tunnels + has been added.
      • - + +
    - -

    6/18/2001 - The current version of Shorewall is 1.1.8. In this -version

    - + +

    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 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 regardless of +which version of iptables is installed.
      • -
    • The .rpm will now install without iproute2 being - installed.
      • +
    • The .rpm will now install without iproute2 + being installed.
      • -
    • The documentation has been cleaned up.
      • +
    • 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 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

    - + +

    5/25/2001 - The current version of Shorewall is 1.1.6. In this version

    + + +
      -
    • You may now rate-limit - the packet log.
      • +
    • 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. 
      • +
    • 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. 
      • +
    • 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/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

    - + +

    5/10/2001 - The current version of Shorewall is 1.1.4. In this version

    + + +
      -
    • Accepting RELATED -connections is now optional.
      • +
    • 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 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.
      • +
    • Corrected rules generated for port redirection.
      • -
    • The order in which iptables kernel modules are - loaded has been corrected (Thanks to Mark Pavlidis). 
      • +
    • 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

    - + +

    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).
      • +
    • 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.
      • +
    • /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.
      • +
    • /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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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 "#".
      • +
    • 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

    - + +

    4/12/2001 - The current version of Shorewall is 1.1.2. In this version

    + + +
      -
    • Port redirection now works again.
      • +
    • Port redirection now works again.
      • -
    • The icmpdef and common chains 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 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.
      • +
    • The LRP Version is renamed "shorwall" for + 8,3 MSDOS file system compatibility.
      • -
    • A couple of LRP-specific problems were corrected.
      • +
    • 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 common chain is traversed from INPUT, + OUTPUT and FORWARD before logging occurs
      • -
    • The source has been cleaned up dramatically
      • +
    • 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. 
      • +
    • 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.
      • +
    • Log messages now indicate the packet disposition.
      • -
    • Error messages have been improved.
      • +
    • Error messages have been improved.
      • -
    • The ability to define zones consisting of an -enumerated set of hosts and/or subnetworks has been - added.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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. 
      • +
    • 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.
      • +
    • 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.
      • +
    • 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).
      • +
    • 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.

    - + +

    3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix + release with no new features.

    + + +
      -
    • The PATH variable in the firewall script now -includes /usr/local/bin and /usr/local/sbin.
      • +
    • 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.
      • +
    • DMZ-related chains are now correctly deleted + if the DMZ is deleted.
      • -
    • The interface OPTIONS for "gw" interfaces are - no longer ignored.
      • +
    • 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 6/17/2003 - Tom Eastep -

    + +

    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 7/19/2003 - Tom Eastep +

    + + +

    Copyright © 2001, 2002 Thomas M. Eastep.

    diff --git a/STABLE/documentation/OPENVPN.html b/STABLE/documentation/OPENVPN.html index 9041e1565..8a673f957 100755 --- a/STABLE/documentation/OPENVPN.html +++ b/STABLE/documentation/OPENVPN.html @@ -1,282 +1,283 @@ - + OpenVPN Tunnels - + - + - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    OpenVPN Tunnels

    -
    - +


    -

    - -

    OpenVPN is a robust and highly configurable VPN (Virtual Private Network) - daemon which can be used to securely link two or more private networks using - an encrypted tunnel over the internet. OpenVPN is an Open Source project -and is licensed under + + +

    OpenVPN is a robust and highly configurable VPN (Virtual Private Network) + daemon which can be used to securely link two or more private networks using + an encrypted tunnel over the internet. OpenVPN is an Open Source project +and is licensed under the GPL. OpenVPN can be downloaded from http://openvpn.sourceforge.net/.
    -

    - +

    +

    OpenVPN support was added to Shorewall in version 1.3.14.
    -

    - +

    +

    Bridging two Masqueraded Networks

    - +

    Suppose that we have the following situation:

    - +

    -

    - -

    We want systems in the 192.168.1.0/24 subnetwork to be able - to communicate with the systems in the 10.0.0.0/8 network. This is accomplished - through use of the /etc/shorewall/tunnels file and the /etc/shorewall/policy +

    + +

    We want systems in the 192.168.1.0/24 subnetwork to be able + to communicate with the systems in the 10.0.0.0/8 network. This is accomplished + through use of the /etc/shorewall/tunnels file and the /etc/shorewall/policy file and OpenVPN.

    - -

    While it was possible to use the Shorewall start and stop - script to start and stop OpenVPN, I decided to use the init script of OpenVPN + +

    While it was possible to use the Shorewall start and stop + script to start and stop OpenVPN, I decided to use the init script of OpenVPN to start and stop it.

    - -

    On each firewall, you will need to declare a zone to represent - the remote subnet. We'll assume that this zone is called 'vpn' and declare + +

    On each firewall, you will need to declare a zone to represent + the remote subnet. We'll assume that this zone is called 'vpn' and declare it in /etc/shorewall/zones on both systems as follows.

    - -
    + +
    - - - - - - - - - - - - - + + + + + + + + + + + + + +
    ZONEDISPLAYCOMMENTS
    vpnVPNRemote Subnet
    ZONEDISPLAYCOMMENTS
    vpnVPNRemote Subnet
    +
    + +

    On system A, the 10.0.0.0/8 will comprise the vpn zone. +In /etc/shorewall/interfaces:

    + +
    + + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    vpntun0
    +     		 
    - -

    On system A, the 10.0.0.0/8 will comprise the vpn -zone. In /etc/shorewall/interfaces:

    - -
    - - - - - - - - - - - - - - - - -
    ZONEINTERFACEBROADCASTOPTIONS
    vpntun0
    -     		 
    -
    - +

    In /etc/shorewall/tunnels on system A, we need the following:

    - -
    + +
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
    TYPEZONEGATEWAYGATEWAY ZONE
    openvpnnet134.28.54.2 
    TYPEZONEGATEWAYGATEWAY ZONE
    openvpnnet134.28.54.2 
    -
    - -

    This entry in /etc/shorewall/tunnels opens the firewall so that OpenVPN - traffic on the default port 5000/udp will be accepted to/from the remote -gateway. If you change the port used by OpenVPN to 7777, you can define /etc/shorewall/tunnels +

    + +

    This entry in /etc/shorewall/tunnels opens the firewall so that OpenVPN + traffic on the default port 5000/udp will be accepted to/from the remote +gateway. If you change the port used by OpenVPN to 7777, you can define /etc/shorewall/tunnels like this:
    -

    - -
    +

    + +
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
    TYPEZONEGATEWAYGATEWAY ZONE
    openvpn:7777net134.28.54.2 
    TYPEZONEGATEWAYGATEWAY ZONE
    openvpn:7777net134.28.54.2 
    -
    - +
    +

    This is the OpenVPN config on system A:

    - -
    + +

    -
    - -
    +
    + +

    dev tun
    - local 206.162.148.9
    - remote 134.28.54.2
    - ifconfig 192.168.99.1 192.168.99.2
    - up ./route-a.up
    - tls-server
    - dh dh1024.pem
    - ca ca.crt
    - cert my-a.crt
    - key my-a.key
    - comp-lzo
    - verb 5
    -

    -
    - -

    Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn + local 206.162.148.9
    + remote 134.28.54.2
    + ifconfig 192.168.99.1 192.168.99.2
    + up ./route-a.up
    + tls-server
    + dh dh1024.pem
    + ca ca.crt
    + cert my-a.crt
    + key my-a.key
    + comp-lzo
    + verb 5
    +

    +
    + +

    Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn zone. In /etc/shorewall/interfaces:

    - -
    + +
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    vpntun0192.168.1.255 
    ZONEINTERFACEBROADCASTOPTIONS
    vpntun0192.168.1.255 
    -
    - +
    +

    In /etc/shorewall/tunnels on system B, we have:

    - -
    + +
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
    TYPEZONEGATEWAYGATEWAY ZONE
    openvpnnet206.191.148.9 
    TYPEZONEGATEWAYGATEWAY ZONE
    openvpnnet206.191.148.9 
    -
    - +
    +

    And in the OpenVPN config on system B:

    - -
    + +

    dev tun
    - local 134.28.54.2
    - remote 206.162.148.9
    - ifconfig 192.168.99.2 192.168.99.1
    - up ./route-b.up
    - tls-client
    - ca ca.crt
    - cert my-b.crt
    - key my-b.key
    - comp-lzo
    - verb 5
    -

    -
    - -

    You will need to allow traffic between the "vpn" zone and - the "loc" zone on both systems -- if you simply want to admit all -traffic in both directions, you can use the policy file:

    - -
    + local 134.28.54.2
    + remote 206.162.148.9
    + ifconfig 192.168.99.2 192.168.99.1
    + up ./route-b.up
    + tls-client
    + ca ca.crt
    + cert my-b.crt
    + key my-b.key
    + comp-lzo
    + verb 5
    +

    +
    + +

    You will need to allow traffic between the "vpn" zone and + the "loc" zone on both systems -- if you simply want to admit all traffic + in both directions, you can use the policy file:

    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVEL
    locvpnACCEPT 
    vpnlocACCEPT 
    SOURCEDESTPOLICYLOG LEVEL
    locvpnACCEPT 
    vpnlocACCEPT 
    -
    - -

    On both systems, restart Shorewall and start OpenVPN. The systems in the +

    + +

    On both systems, restart Shorewall and start OpenVPN. The systems in the two masqueraded subnetworks can now talk to each other.

    - -

    Updated 2/4/2003 - Tom Eastep + +

    Updated 2/4/2003 - Tom Eastep and Simon Mater
    -

    - +

    +

    - -

    Copyright + +

    Copyright © 2003 Thomas M. Eastep. and Simon Mater
    -

    -
    +

    +
    +


    diff --git a/STABLE/documentation/PPTP.htm b/STABLE/documentation/PPTP.htm index 6b464faba..369bb3331 100644 --- a/STABLE/documentation/PPTP.htm +++ b/STABLE/documentation/PPTP.htm @@ -1,926 +1,928 @@ - + - + - + - + Shorewall PPTP - + - - - + + - - - -
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    PPTP

    -
    - -

    NOTE: I am no longer attempting to maintain MPPE patches for current -Linux kernel's and pppd. I recommend that you refer to the following URLs -for information about installing MPPE into your kernel and pppd.

    -

    The Linux PPTP client project -has a nice GUI for configuring and managing VPN connections where your -Linux system is the PPTP client. This is what I currently use. I am no longer -running PoPToP but rather I use the PPTP Server included with XP Professional -(see PPTP Server running behind your Firewall -below).

    -    http://pptpclient.sourceforge.net -(Everything you need to run a PPTP client).
    -    http://www.poptop.org (The 'kernelmod' -package can be used to quickly install MPPE into your kernel without rebooting).
    -

    I am leaving the instructions for building MPPE-enabled kernels and pppd -in the text below for those who may wish to obtain the relevant current patches -and "roll their own".
    -

    -
    -

    Shorewall easily supports PPTP in a number of configurations:

    - - - -

    1. PPTP Server Running on your -Firewall

    - -

    I will try to give you an idea of how to set up a PPTP server on your -firewall system. This isn't a detailed HOWTO but rather an example of how -I have set up a working PPTP server on my own firewall.

    - -

    The steps involved are:

    - -
      -
    1. Patching and building pppd
      2. -
    2. Patching and building your Kernel
      3. -
    3. Configuring Samba
      4. -
    4. Configuring pppd
      5. -
    5. Configuring pptpd
      6. -
    6. Configuring Shorewall
      7. - -
    - -

    Patching and Building pppd

    - -

    To run pppd on a 2.4 kernel, you need the pppd 2.4.1 or later. The primary - site for releases of pppd is ftp://ftp.samba.org/pub/ppp.

    - -

    You will need the following patches:

    - - - -

    You may also want the following patch if you want to require remote hosts -to use encryption:

    - - - -

    Un-tar the pppd source and uncompress the patches into one directory (the - patches and the ppp-2.4.1 directory are all in a single parent directory):

    - -
      -
    • cd ppp-2.4.1
      • -
    • patch -p1 < ../ppp-2.4.0-openssl-0.9.6-mppe.patch
      • -
    • patch -p1 < ../ppp-2.4.1-MSCHAPv2-fix.patch
      • -
    • (Optional) patch -p1 < ../require-mppe.diff
      • -
    • ./configure
      • -
    • make
      • - -
    - -

    You will need to install the resulting binary on your firewall system. -To do that, I NFS mount my source filesystem and use "make install" from -the ppp-2.4.1 directory.

    - -

    Patching and Building your Kernel

    - -

    You will need one of the following patches depending on your kernel version:

    - - - -

    Uncompress the patch into the same directory where your top-level kernel - source is located and:

    - -
      -
    • cd <your GNU/Linux source top-level directory>
      • -
    • patch -p1 < ../linux-2.4.16-openssl-0.9.6b-mppe.patch
      • - -
    - -

    Now configure your kernel. Here is my ppp configuration:

    - -
    -

    -

    -
    - -

    Configuring Samba

    - -

    You will need a WINS server (Samba configured to run as a WINS server -is fine). Global section from /etc/samba/smb.conf on my WINS server (192.168.1.3) -is:

    - -
    - 
    [global]
         workgroup = TDM-NSTOP
         netbios name = WOOKIE
         server string = GNU/Linux Box
         encrypt passwords = Yes
         log file = /var/log/samba/%m.log
         max log size = 0
         socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
         os level = 65
         domain master = True
         preferred master = True
         dns proxy = No
         wins support = Yes
         printing = lprng

    [homes]
         comment = Home Directories
         valid users = %S
         read only = No
         create mask = 0664
         directory mask = 0775

    [printers]
         comment = All Printers
         path = /var/spool/samba
         printable = Yes
    -
    - -

    Configuring pppd

    - -

    Here is a copy of my /etc/ppp/options.poptop file:

    - -
    -

    ipparam PoPToP
    - lock
    - mtu 1490
    - mru 1490
    - ms-wins 192.168.1.3
    - ms-dns 206.124.146.177
    - multilink
    - proxyarp
    - auth
    - +chap
    - +chapms
    - +chapms-v2
    - ipcp-accept-local
    - ipcp-accept-remote
    - lcp-echo-failure 30
    - lcp-echo-interval 5
    - deflate 0
    - mppe-128
    - mppe-stateless
    - require-mppe
    - require-mppe-stateless

    -
    - -

    Notes:

    - -
      -
    • System 192.168.1.3 acts as a WINS server so I have included that -IP as the 'ms-wins' value.
      • -
    • I have pointed the remote clients at my DNS server -- it has external - address 206.124.146.177.
      • -
    • I am requiring 128-bit stateless compression (my kernel is built -with the 'require-mppe.diff' patch mentioned above.
      • - -
    - -

    Here's my /etc/ppp/chap-secrets:

    - -
    -

    Secrets for authentication using CHAP
    - # client        server    secret    IP addresses
    - CPQTDM\\TEastep *         <shhhhhh> 192.168.1.7
    - TEastep         *         <shhhhhh> 192.168.1.7

    -
    - -

    I am the only user who connects to the server but I may connect either -with or without a domain being specified. The system I connect from is my -laptop so I give it the same IP address when tunneled in at it has when I -use its wireless LAN card around the house.

    - -

    You will also want the following in /etc/modules.conf:

    - -
         alias ppp-compress-18 ppp_mppe
         alias ppp-compress-21 bsd_comp
         alias ppp-compress-24 ppp_deflate
         alias ppp-compress-26 ppp_deflate
    - -

    Configuring pptpd

    - -

    PoPTop (pptpd) is available from http://poptop.lineo.com/.

    - -

    Here is a copy of my /etc/pptpd.conf file:

    - -
    -

    option /etc/ppp/options.poptop
    - speed 115200
    - localip 192.168.1.254
    - remoteip 192.168.1.33-38

    -
    - -

    Notes:

    - -
      -
    • I specify the /etc/ppp/options.poptop file as my ppp options file -(I have several).
      • -
    • The local IP is the same as my internal interface's (192.168.1.254).
      • -
    • I have assigned a remote IP range that overlaps my local network. -This, together with 'proxyarp' in my /etc/ppp/options.poptop file make -the remote hosts look like they are part of the local subnetwork.
      • - -
    - -

    I use this file to start/stop pptpd -- I have this in /etc/init.d/pptpd:

    - -
    -

    #!/bin/sh
    - #
    - # /etc/rc.d/init.d/pptpd
    - #
    - # chkconfig: 5 12 85
    - # description: control pptp server
    - #
    -
    - case "$1" in
    - start)
    -     echo 1 > /proc/sys/net/ipv4/ip_forward
    -     modprobe ppp_async
    -     modprobe ppp_generic
    -     modprobe ppp_mppe
    -     modprobe slhc
    -     if /usr/local/sbin/pptpd; then
    -         touch /var/lock/subsys/pptpd
    -     fi
    -     ;;
    - stop)
    -     killall pptpd
    -     rm -f /var/lock/subsys/pptpd
    -     ;;
    - restart)
    -     killall pptpd
    -     if /usr/local/sbin/pptpd; then
    -         touch /var/lock/subsys/pptpd
    -     fi
    -     ;;
    - status)
    -     ifconfig
    -     ;;
    - *)
    -     echo "Usage: $0 {start|stop|restart|status}"
    -     ;;
    - esac

    -
    - -

    Configuring Shorewall

    - -

    I consider hosts connected to my PPTP server to be just like local systems. - My key Shorewall entries are:

    - -

    /etc/shorewall/zones:

    - -
    - - - - - - - - - - - - - - - - - - - -
    ZONEDISPLAYCOMMENTS
    netInternetThe Internet
    locLocalMy Local Network including remote PPTP clients
    -
    - -

    /etc/shorewall/interfaces:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONEINTERFACEBROADCASTOPTIONS
    neteth0206.124.146.255norfc1918
    loceth2192.168.1.255 
    -ppp+  
    -
    - -

    /etc/shorewall/hosts:

    - -
    - - - - - - - - - - - - - - - - - - - -
    ZONEHOST(S)OPTIONS
    loceth2:192.168.1.0/24
    locppp+:192.168.1.0/24 
    -
    - -

    /etc/shorewall/policy:

    - -
    - - - - - - - - - - - - - - - - -
    SOURCEDESTPOLICYLOG LEVEL
    loclocACCEPT 
    -
    - -

    /etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b):

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACCEPTnetfwtcp1723  
    ACCEPTnetfw47-  
    ACCEPTfwnet47-  
    -
    - -

    /etc/shoreawll/tunnels (For Shorewall versions 1.3.10 and -later)
    -

    - -
    - - - - - - - - - - - - - - - - -
    TYPE
    -     		ZONE
    -     		GATEWAY
    -     		GATEWAY ZONE
    -
    pptpserver
    -     		net
    -     		0.0.0.0/0
    -
    -
    -
    - -


    - Note: I have multiple ppp interfaces on my firewall. If you have a single -ppp interface, you probably want:

    - -

    /etc/shorewall/interfaces:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONEINTERFACEBROADCASTOPTIONS
    neteth0206.124.146.255norfc1918
    loceth2192.168.1.255 
    locppp0  
    -
    - -

    and no entries in /etc/shorewall/hosts.

    - -

    2. PPTP Server Running Behind -your Firewall

    - -

    If you have a single external IP address, add the following to your -/etc/shorewall/rules file:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    DNATnetloc:<server address>tcp1723  
    DNATnetloc:<server address>47-  
    - -

    If you have multiple external IP address and you want to forward a single -<external address>, add the following to your /etc/shorewall/rules -file:

    - -

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    DNATnetloc:<server address>tcp1723-<external address>
    DNATnetloc:<server address>47--<external address>
    -

    - -

    3. PPTP Clients Running Behind -your Firewall

    - -

    You shouldn't have to take any special action for this case unless you -wish to connect multiple clients to the same external server. In that case, -you will need to follow the instructions at http://www.impsec.org/linux/masquerade/ip_masq_vpn.html. - I recommend that you also add these two lines to your /etc/shorewall/modules - file:

    - -
    -

    loadmodule ip_conntrack_pptp
    - loadmodule ip_nat_pptp

    -
    - -

    4. PPTP Client Running on your -Firewall.

    - -

    The PPTP GNU/Linux client is available at http://sourceforge.net/projects/pptpclient/.    - Rather than use the configuration script that comes with the client, I built -my own. I also build my own kernel as described above - rather than using the mppe package that is available with the client. My -/etc/ppp/options file is mostly unchanged from what came with the client (see -below).

    - -

    The key elements of this setup are as follows:

    - +

    NOTE: I am no longer attempting to maintain MPPE patches for current Linux +kernel's and pppd. I recommend that you refer to the following URLs for information +about installing MPPE into your kernel and pppd.

    + +

    The Linux PPTP client project +has a nice GUI for configuring and managing VPN connections where your +Linux system is the PPTP client. This is what I currently use. I am no longer +running PoPToP but rather I use the PPTP Server included with XP Professional +(see PPTP Server running behind your Firewall +below).

    +     http://pptpclient.sourceforge.net +(Everything you need to run a PPTP client).
    +     http://www.poptop.org (The 'kernelmod' +package can be used to quickly install MPPE into your kernel without rebooting).
    + +

    I am leaving the instructions for building MPPE-enabled kernels and pppd +in the text below for those who may wish to obtain the relevant current patches +and "roll their own".
    +

    + +
    +

    Shorewall easily supports PPTP in a number of configurations:

    + + + +

    1. PPTP Server Running on your Firewall

    + +

    I will try to give you an idea of how to set up a PPTP server on your firewall +system. This isn't a detailed HOWTO but rather an example of how I have set +up a working PPTP server on my own firewall.

    + +

    The steps involved are:

    +
      -
    1. Define a zone for the remote network accessed via PPTP.
      2. -
    2. Associate that zone with a ppp interface.
      3. -
    3. Define rules for PPTP traffic to/from the firewall.
      4. -
    4. Define rules for traffic two and from the remote zone.
      5. - +
    5. Patching and building pppd
      6. +
    6. Patching and building your Kernel
      7. +
    7. Configuring Samba
      8. +
    8. Configuring pppd
      9. +
    9. Configuring pptpd
      10. +
    10. Configuring Shorewall
      11. +
    - -

    Here are examples from my setup:

    - -

    /etc/shorewall/zones

    - -
    + +

    Patching and Building pppd

    + +

    To run pppd on a 2.4 kernel, you need the pppd 2.4.1 or later. The primary + site for releases of pppd is ftp://ftp.samba.org/pub/ppp.

    + +

    You will need the following patches:

    + + + +

    You may also want the following patch if you want to require remote hosts + to use encryption:

    + + + +

    Un-tar the pppd source and uncompress the patches into one directory (the + patches and the ppp-2.4.1 directory are all in a single parent directory):

    + +
      +
    • cd ppp-2.4.1
      • +
    • patch -p1 < ../ppp-2.4.0-openssl-0.9.6-mppe.patch
      • +
    • patch -p1 < ../ppp-2.4.1-MSCHAPv2-fix.patch
      • +
    • (Optional) patch -p1 < ../require-mppe.diff
      • +
    • ./configure
      • +
    • make
      • + +
    + +

    You will need to install the resulting binary on your firewall system. + To do that, I NFS mount my source filesystem and use "make install" from +the ppp-2.4.1 directory.

    + +

    Patching and Building your Kernel

    + +

    You will need one of the following patches depending on your kernel version:

    + + + +

    Uncompress the patch into the same directory where your top-level kernel + source is located and:

    + +
      +
    • cd <your GNU/Linux source top-level directory>
      • +
    • patch -p1 < ../linux-2.4.16-openssl-0.9.6b-mppe.patch
      • + +
    + +

    Now configure your kernel. Here is my ppp configuration:

    + +
    +

    +

    +
    + +

    Configuring Samba

    + +

    You will need a WINS server (Samba configured to run as a WINS server is + fine). Global section from /etc/samba/smb.conf on my WINS server (192.168.1.3) + is:

    + +
    + 
    [global]
         workgroup = TDM-NSTOP
         netbios name = WOOKIE
         server string = GNU/Linux Box
         encrypt passwords = Yes
         log file = /var/log/samba/%m.log
         max log size = 0
         socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
         os level = 65
         domain master = True
         preferred master = True
         dns proxy = No
         wins support = Yes
         printing = lprng

    [homes]
         comment = Home Directories
         valid users = %S
         read only = No
         create mask = 0664
         directory mask = 0775

    [printers]
         comment = All Printers
         path = /var/spool/samba
         printable = Yes
    +
    + +

    Configuring pppd

    + +

    Here is a copy of my /etc/ppp/options.poptop file:

    + +
    +

    ipparam PoPToP
    + lock
    + mtu 1490
    + mru 1490
    + ms-wins 192.168.1.3
    + ms-dns 206.124.146.177
    + multilink
    + proxyarp
    + auth
    + +chap
    + +chapms
    + +chapms-v2
    + ipcp-accept-local
    + ipcp-accept-remote
    + lcp-echo-failure 30
    + lcp-echo-interval 5
    + deflate 0
    + mppe-128
    + mppe-stateless
    + require-mppe
    + require-mppe-stateless

    +
    + +

    Notes:

    + +
      +
    • System 192.168.1.3 acts as a WINS server so I have included that + IP as the 'ms-wins' value.
      • +
    • I have pointed the remote clients at my DNS server -- it has external + address 206.124.146.177.
      • +
    • I am requiring 128-bit stateless compression (my kernel is built + with the 'require-mppe.diff' patch mentioned above.
      • + +
    + +

    Here's my /etc/ppp/chap-secrets:

    + +
    +

    Secrets for authentication using CHAP
    + # client        server    secret    IP addresses
    + CPQTDM\\TEastep *         <shhhhhh> 192.168.1.7
    + TEastep         *         <shhhhhh> 192.168.1.7

    +
    + +

    I am the only user who connects to the server but I may connect either + with or without a domain being specified. The system I connect from is my + laptop so I give it the same IP address when tunneled in at it has when +I use its wireless LAN card around the house.

    + +

    You will also want the following in /etc/modules.conf:

    + +
         alias ppp-compress-18 ppp_mppe
         alias ppp-compress-21 bsd_comp
         alias ppp-compress-24 ppp_deflate
         alias ppp-compress-26 ppp_deflate
    + +

    Configuring pptpd

    + +

    PoPTop (pptpd) is available from http://poptop.lineo.com/.

    + +

    Here is a copy of my /etc/pptpd.conf file:

    + +
    +

    option /etc/ppp/options.poptop
    + speed 115200
    + localip 192.168.1.254
    + remoteip 192.168.1.33-38

    +
    + +

    Notes:

    + +
      +
    • I specify the /etc/ppp/options.poptop file as my ppp options file + (I have several).
      • +
    • The local IP is the same as my internal interface's (192.168.1.254).
      • +
    • I have assigned a remote IP range that overlaps my local network. + This, together with 'proxyarp' in my /etc/ppp/options.poptop file make + the remote hosts look like they are part of the local subnetwork.
      • + +
    + +

    I use this file to start/stop pptpd -- I have this in /etc/init.d/pptpd:

    + +
    +

    #!/bin/sh
    + #
    + # /etc/rc.d/init.d/pptpd
    + #
    + # chkconfig: 5 12 85
    + # description: control pptp server
    + #
    +
    + case "$1" in
    + start)
    +     echo 1 > /proc/sys/net/ipv4/ip_forward
    +     modprobe ppp_async
    +     modprobe ppp_generic
    +     modprobe ppp_mppe
    +     modprobe slhc
    +     if /usr/local/sbin/pptpd; then
    +         touch /var/lock/subsys/pptpd
    +     fi
    +     ;;
    + stop)
    +     killall pptpd
    +     rm -f /var/lock/subsys/pptpd
    +     ;;
    + restart)
    +     killall pptpd
    +     if /usr/local/sbin/pptpd; then
    +         touch /var/lock/subsys/pptpd
    +     fi
    +     ;;
    + status)
    +     ifconfig
    +     ;;
    + *)
    +     echo "Usage: $0 {start|stop|restart|status}"
    +     ;;
    + esac

    +
    + +

    Configuring Shorewall

    + +

    I consider hosts connected to my PPTP server to be just like local systems. + My key Shorewall entries are:

    + +

    /etc/shorewall/zones:

    + +
    - + + + + + + - - - - - - - - - - - + + + + + + + + + + +
    ZONEDISPLAYCOMMENTS
    ZONEDISPLAYCOMMENTS
    cpqCompaqCompaq Intranet
    netInternetThe Internet
    locLocalMy Local Network including remote PPTP clients
    -
    - -

    /etc/shorewall/interfaces

    - -
    +
    + +

    /etc/shorewall/interfaces:

    + +
    - + + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    ZONEINTERFACEBROADCASTOPTIONS
    -ppp+  
    neteth0206.124.146.255norfc1918
    loceth2192.168.1.255 
    -ppp+  
    -
    - -

    /etc/shorewall/hosts

    - -
    +
    + +

    /etc/shorewall/hosts:

    + +
    - + + + + + + - - - - - - - - - - - + + + + + + + + + + +
    ZONEHOST(S)OPTIONS
    ZONEHOST(S)OPTIONS
    -ppp+:!192.168.1.0/24 
    loceth2:192.168.1.0/24
    +
    locppp+:192.168.1.0/24 
    -
    - -

    /etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b)

    - -
    +
    + +

    /etc/shorewall/policy:

    + +
    + + + + + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVEL
    loclocACCEPT 
    +
    + +

    /etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b):

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTnetfwtcp1723  
    ACCEPTnetfw47-  
    ACCEPTfwnet47-  
    +
    + +

    /etc/shoreawll/tunnels (For Shorewall versions 1.3.10 +and later)
    +

    - - +
    +
    + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACCEPTfwnettcp1723  
    ACCEPTfwnet47-  
    TYPE
    +     		ZONE
    +     		GATEWAY
    +     		GATEWAY ZONE
    +
    pptpserver
    +     		net
    +     		0.0.0.0/0
    +
    +
    +
    + +


    + Note: I have multiple ppp interfaces on my firewall. If you have a single + ppp interface, you probably want:

    + +

    /etc/shorewall/interfaces:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    neteth0206.124.146.255norfc1918
    loceth2192.168.1.255 
    locppp0  
    +
    + +

    and no entries in /etc/shorewall/hosts.

    + +

    2. PPTP Server Running Behind + your Firewall

    + +

    If you have a single external IP address, add the following to your /etc/shorewall/rules +file:

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    DNATnetloc:<server address>tcp1723  
    DNATnetloc:<server address>47-  
    + +

    If you have multiple external IP address and you want to forward a single + <external address>, add the following to your /etc/shorewall/rules + file:

    + +

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    DNATnetloc:<server address>tcp1723-<external address>
    DNATnetloc:<server address>47--<external address>
    +

    + +

    3. PPTP Clients Running Behind + your Firewall

    + +

    You shouldn't have to take any special action for this case unless you + wish to connect multiple clients to the same external server. In that case, + you will need to follow the instructions at http://www.impsec.org/linux/masquerade/ip_masq_vpn.html. + I recommend that you also add these two lines to your /etc/shorewall/modules + file:

    + +
    +

    loadmodule ip_conntrack_pptp
    + loadmodule ip_nat_pptp

    - + +

    4. PPTP Client Running on your Firewall.

    + +

    The PPTP GNU/Linux client is available at http://sourceforge.net/projects/pptpclient/.    + Rather than use the configuration script that comes with the client, I +built my own. I also build my own kernel as described +above rather than using the mppe package that is available with the +client. My /etc/ppp/options file is mostly unchanged from what came with +the client (see below).

    + +

    The key elements of this setup are as follows:

    + +
      +
    1. Define a zone for the remote network accessed via PPTP.
      2. +
    2. Associate that zone with a ppp interface.
      3. +
    3. Define rules for PPTP traffic to/from the firewall.
      4. +
    4. Define rules for traffic two and from the remote zone.
      5. + +
    + +

    Here are examples from my setup:

    + +

    /etc/shorewall/zones

    + +
    + + + + + + + + + + + + + + +
    ZONEDISPLAYCOMMENTS
    cpqCompaqCompaq Intranet
    +
    + +

    /etc/shorewall/interfaces

    + +
    + + + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    -ppp+  
    +
    + +

    /etc/shorewall/hosts

    + +
    + + + + + + + + + + + + + + +
    ZONEHOST(S)OPTIONS
    -ppp+:!192.168.1.0/24 
    +
    + +

    /etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b)

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTfwnettcp1723  
    ACCEPTfwnet47-  
    +
    +

    /etc/shorewall/tunnels (For Shorewall versions 1.3.10 and later)
    -

    - -
    +

    + +
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
    TYPE
    -     		ZONE
    -     		GATEWAY
    -     		GATEWAY ZONE
    -
    pptpclient
    -     		net
    -     		0.0.0.0/0
    -
    -
    TYPE
    +     		ZONE
    +     		GATEWAY
    +     		GATEWAY ZONE
    +
    pptpclient
    +     		net
    +     		0.0.0.0/0
    +
    +
    -
    -
    - -

    I use the combination of interface and hosts file to define the 'cpq' -zone because I also run a PPTP server on my firewall (see above). Using this - technique allows me to distinguish clients of my own PPTP server from arbitrary - hosts at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP clients +
    +

    + +

    I use the combination of interface and hosts file to define the 'cpq' zone +because I also run a PPTP server on my firewall (see above). Using this +technique allows me to distinguish clients of my own PPTP server from arbitrary + hosts at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP clients and Compaq doesn't use that RFC1918 Class C subnet.

    - -

    I use this script in /etc/init.d to control the client. The reason that -I disable ECN when connecting is that the Compaq tunnel servers don't do -ECN yet and reject the initial TCP connection request if I enable ECN :-( + +

    I use this script in /etc/init.d to control the client. The reason that + I disable ECN when connecting is that the Compaq tunnel servers don't do +ECN yet and reject the initial TCP connection request if I enable ECN :-(

    - -
    + +

    #!/bin/sh
    - #
    - # /etc/rc.d/init.d/pptp
    - #
    - # chkconfig: 5 60 85
    - # description: PPTP Link Control
    - #
    - NAME="Tandem"
    - ADDRESS=tunnel-tandem.compaq.com
    - USER='Tandem\tommy'
    - ECN=0
    - DEBUG=
    -
    - start_pptp() {
    -     echo $ECN > /proc/sys/net/ipv4/tcp_ecn
    -     if /usr/sbin/pptp $ADDRESS user $USER noauth $DEBUG; then
    -         touch /var/lock/subsys/pptp
    -         echo "PPTP Connection to $NAME Started"
    -     fi
    - }
    -
    - stop_pptp() {
    -     if killall /usr/sbin/pptp 2> /dev/null; then
    -         echo "Stopped pptp"
    -     else
    -         rm -f /var/run/pptp/*
    -     fi
    -
    -     # if killall pppd; then
    -     # echo "Stopped pppd"
    -     # fi
    -
    -     rm -f /var/lock/subsys/pptp
    -
    -     echo 1 > /proc/sys/net/ipv4/tcp_ecn
    - }
    -
    -
    - case "$1" in
    - start)
    -     echo "Starting PPTP Connection to ${NAME}..."
    -     start_pptp
    -     ;;
    - stop)
    -     echo "Stopping $NAME PPTP Connection..."
    -     stop_pptp
    -     ;;
    - restart)
    -     echo "Restarting $NAME PPTP Connection..."
    -     stop_pptp
    -     start_pptp
    -     ;;
    - status)
    -     ifconfig
    -     ;;
    - *)
    -     echo "Usage: $0 {start|stop|restart|status}"
    -     ;;
    - esac
    -

    -
    - + #
    + # /etc/rc.d/init.d/pptp
    + #
    + # chkconfig: 5 60 85
    + # description: PPTP Link Control
    + #
    + NAME="Tandem"
    + ADDRESS=tunnel-tandem.compaq.com
    + USER='Tandem\tommy'
    + ECN=0
    + DEBUG=
    +
    + start_pptp() {
    +     echo $ECN > /proc/sys/net/ipv4/tcp_ecn
    +     if /usr/sbin/pptp $ADDRESS user $USER noauth $DEBUG; then
    +         touch /var/lock/subsys/pptp
    +         echo "PPTP Connection to $NAME Started"
    +     fi
    + }
    +
    + stop_pptp() {
    +     if killall /usr/sbin/pptp 2> /dev/null; then
    +         echo "Stopped pptp"
    +     else
    +         rm -f /var/run/pptp/*
    +     fi
    +
    +     # if killall pppd; then
    +     # echo "Stopped pppd"
    +     # fi
    +
    +     rm -f /var/lock/subsys/pptp
    +
    +     echo 1 > /proc/sys/net/ipv4/tcp_ecn
    + }
    +
    +
    + case "$1" in
    + start)
    +     echo "Starting PPTP Connection to ${NAME}..."
    +     start_pptp
    +     ;;
    + stop)
    +     echo "Stopping $NAME PPTP Connection..."
    +     stop_pptp
    +     ;;
    + restart)
    +     echo "Restarting $NAME PPTP Connection..."
    +     stop_pptp
    +     start_pptp
    +     ;;
    + status)
    +     ifconfig
    +     ;;
    + *)
    +     echo "Usage: $0 {start|stop|restart|status}"
    +     ;;
    + esac
    +

    +
    +

    Here's my /etc/ppp/options file:

    - -
    + +

    #
    - # Identify this connection
    - #
    - ipparam Compaq
    - #
    - # Lock the port
    - #
    - lock
    - #
    - # We don't need the tunnel server to authenticate itself
    - #
    - noauth
    -
    - +chap
    - +chapms
    - +chapms-v2
    -
    - multilink
    - mrru 1614
    - #
    - # Turn off transmission protocols we know won't be used
    - #
    - nobsdcomp
    - nodeflate
    -
    - #
    - # We want MPPE
    - #
    - mppe-128
    - mppe-stateless
    -
    - #
    - # We want a sane mtu/mru
    - #
    - mtu 1000
    - mru 1000
    -
    - #
    - # Time this thing out of it goes poof
    - #
    - lcp-echo-failure 10
    - lcp-echo-interval 10

    -
    - -

    My /etc/ppp/ip-up.local file sets up the routes that I need to route Compaq - traffic through the PPTP tunnel:

    - -
    + # Identify this connection
    + #
    + ipparam Compaq
    + #
    + # Lock the port
    + #
    + lock
    + #
    + # We don't need the tunnel server to authenticate itself
    + #
    + noauth
    +
    + +chap
    + +chapms
    + +chapms-v2
    +
    + multilink
    + mrru 1614
    + #
    + # Turn off transmission protocols we know won't be used
    + #
    + nobsdcomp
    + nodeflate
    +
    + #
    + # We want MPPE
    + #
    + mppe-128
    + mppe-stateless
    +
    + #
    + # We want a sane mtu/mru
    + #
    + mtu 1000
    + mru 1000
    +
    + #
    + # Time this thing out of it goes poof
    + #
    + lcp-echo-failure 10
    + lcp-echo-interval 10

    +
    + +

    My /etc/ppp/ip-up.local file sets up the routes that I need to route Compaq + traffic through the PPTP tunnel:

    + +

    #/bin/sh
    -
    - case $6 in
    - Compaq)
    -     route add -net 16.0.0.0 netmask 255.0.0.0 gw $5 $1
    -     route add -net 130.252.0.0 netmask 255.255.0.0 gw $5 $1
    -     route add -net 131.124.0.0 netmask 255.255.0.0 gw $5 $1
    -     ...
    -     ;;
    - esac

    -
    - -

    Finally, I run the following script every five minutes under crond to - restart the tunnel if it fails:

    - +
    + case $6 in
    + Compaq)
    +     route add -net 16.0.0.0 netmask 255.0.0.0 gw $5 $1
    +     route add -net 130.252.0.0 netmask 255.255.0.0 gw $5 $1
    +     route add -net 131.124.0.0 netmask 255.255.0.0 gw $5 $1
    +     ...
    +     ;;
    + esac

    +
    + +

    Finally, I run the following script every five minutes under crond to + restart the tunnel if it fails:

    + 
         #!/bin/sh
         restart_pptp() {
             /sbin/service pptp stop
             sleep 10
             if /sbin/service pptp start; then
                 /usr/bin/logger "PPTP Restarted"
             fi
         }

         if [ -n "`ps ax | grep /usr/sbin/pptp | grep -v grep`" ]; then
             exit 0
         fi

         echo "Attempting to restart PPTP"

         restart_pptp > /dev/null 2>&1 &
    - -

    Here's a script - and corresponding ip-up.local from Here's a script + and corresponding ip-up.local from Jerry Vonau that controls two PPTP connections.

    - +

    Last modified 5/15/2003 - Tom Eastep

    - +

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

    -
    +
    +


    diff --git a/STABLE/documentation/ProxyARP.htm b/STABLE/documentation/ProxyARP.htm index 53549db45..538a880b4 100644 --- a/STABLE/documentation/ProxyARP.htm +++ b/STABLE/documentation/ProxyARP.htm @@ -1,188 +1,190 @@ - + Shorewall Proxy ARP - + - + - + - + - - - + + - - - + + + +
    + bgcolor="#3366ff" height="90"> +

    Proxy ARP

    -
    - -

    Proxy ARP allows you to insert a firewall in front of a set of servers - without changing their IP addresses and without having to re-subnet. - Before you try to use this technique, I strongly recommend that you read + +

    Proxy ARP allows you to insert a firewall in front of a set of servers + without changing their IP addresses and without having to re-subnet. + Before you try to use this technique, I strongly recommend that you read the Shorewall Setup Guide.

    - +

    The following figure represents a Proxy ARP environment.

    - -
    + +

    -

    - +

    +
    -
    - -

    Proxy ARP can be used to make the systems with addresses - 130.252.100.18 and 130.252.100.19 appear to be on the upper (130.252.100.*) - subnet.  Assuming that the upper firewall interface is eth0 and the - lower interface is eth1, this is accomplished using the following entries +

    + +

    Proxy ARP can be used to make the systems with addresses + 130.252.100.18 and 130.252.100.19 appear to be on the upper (130.252.100.*) + subnet.  Assuming that the upper firewall interface is eth0 and the + lower interface is eth1, this is accomplished using the following entries in /etc/shorewall/proxyarp:

    - -
    + +
    - - - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVEROUTE
    130.252.100.18eth1eth0no
    130.252.100.19eth1eth0no
    ADDRESSINTERFACEEXTERNALHAVEROUTE
    130.252.100.18eth1eth0no
    130.252.100.19eth1eth0no
    -
    - -

    Be sure that the internal systems (130.242.100.18 and 130.252.100.19  - in the above example) are not included in any specification in /etc/shorewall/masq +

    + +

    Be sure that the internal systems (130.242.100.18 and 130.252.100.19  + in the above example) are not included in any specification in /etc/shorewall/masq or /etc/shorewall/nat.

    - -

    Note that I've used an RFC1918 IP address for eth1 - that IP address is + +

    Note that I've used an RFC1918 IP address for eth1 - that IP address is irrelevant.

    - -

    The lower systems (130.252.100.18 and 130.252.100.19) should have their - subnet mask and default gateway configured exactly the same way that - the Firewall system's eth0 is configured. In other words, they should -be configured just like they would be if they were parallel to the firewall + +

    The lower systems (130.252.100.18 and 130.252.100.19) should have their + subnet mask and default gateway configured exactly the same way that + the Firewall system's eth0 is configured. In other words, they should +be configured just like they would be if they were parallel to the firewall rather than behind it.
    -

    - -

    NOTE: Do not add the Proxy ARP'ed address(es) -(130.252.100.18 and 130.252.100.19 in the above example)  to the external +

    + +

    NOTE: Do not add the Proxy ARP'ed address(es) +(130.252.100.18 and 130.252.100.19 in the above example)  to the external interface (eth0 in this example) of the firewall.
    -

    +

    +
    - -
    -

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

    +

    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. There are a couple of things that you can try:
    -

    - +

    +
      -
    1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP Illustrated, - Vol 1 reveals that a
      -
      - "gratuitous" ARP packet should cause the ISP's router to refresh their -ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the -MAC address for its own IP; in addition to ensuring that the IP address isn't - a duplicate...
      -
      - "if the host sending the gratuitous ARP has just changed its hardware -address..., this packet causes any other host...that has an entry in its +
    2. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP +Illustrated, Vol 1 reveals that a
      +
      + "gratuitous" ARP packet should cause the ISP's router to refresh their +ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the +MAC address for its own IP; in addition to ensuring that the IP address +isn't a duplicate...
      +
      + "if the host sending the gratuitous ARP has just changed its hardware +address..., this packet causes any other host...that has an entry in its cache for the old hardware address to update its ARP cache entry accordingly."
      -
      - Which is, of course, exactly what you want to do when you switch a host - from being exposed to the Internet to behind Shorewall using proxy ARP (or - static NAT for that matter). Happily enough, recent versions of Redhat's +
      + Which is, of course, exactly what you want to do when you switch a host + from being exposed to the Internet to behind Shorewall using proxy ARP (or + static NAT for that matter). Happily enough, recent versions of Redhat's iputils package include "arping", whose "-U" flag does just that:
      -
      -     arping -U -I <net if> <newly +
      +     arping -U -I <net if> <newly proxied IP>
      -     arping -U -I eth0 66.58.99.83 # for example
      +     arping -U -I eth0 66.58.99.83 # for example
      +
      + Stevens goes on to mention that not all systems respond correctly to +gratuitous ARPs, but googling for "arping -U" seems to support the idea +that it works most of the time.

      - Stevens goes on to mention that not all systems respond correctly to gratuitous - ARPs, but googling for "arping -U" seems to support the idea that it works - most of the time.
      -
      - To use arping with Proxy ARP in the above example, you would have to:
      -
      -     shorewall clear
      -           ip addr add 130.252.100.18 + To use arping with Proxy ARP in the above example, you would have to:
      +
      +     shorewall clear
      +           ip addr add 130.252.100.18 dev eth0
      -     ip addr add 130.252.100.19 dev eth0
      -     arping -U -I eth0 130.252.100.18
      -     arping -U -I eth0 130.252.100.19
      -     ip addr del 130.252.100.18 dev eth0
      -     ip addr del 130.252.100.19 dev eth0
      -     shorewall start
      -
      -
      3. -
    3. You can call your ISP and ask them to purge the stale ARP cache +     ip addr add 130.252.100.19 dev eth0
      +     arping -U -I eth0 130.252.100.18
      +     arping -U -I eth0 130.252.100.19
      +     ip addr del 130.252.100.18 dev eth0
      +     ip addr del 130.252.100.19 dev eth0
      +     shorewall start
      +
      +
      4. +
    4. 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.
      5. - +
    - 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 + You can determine if your ISP's gateway ARP cache is stale using ping + and tcpdump. Suppose that we suspect that the gateway router has a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:
    - -
    + +
    	tcpdump -nei eth0 icmp
    -
    - -
    -

    Now from 130.252.100.19, ping the ISP's gateway (which we +

    + +
    +

    Now from 130.252.100.19, ping the ISP's gateway (which we will assume is 130.252.100.254):

    -
    - -
    +
    + +
    	ping 130.252.100.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: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)
    	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.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 the system on the lower left. In other words, the - gateway's ARP cache still associates 130.252.100.19 with the NIC in that - system rather than with the firewall's eth0.

    -
    - + +
    +
    	13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)
    	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.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 the system on the lower left. In other words, +the gateway's ARP cache still associates 130.252.100.19 with the NIC +in that system rather than with the firewall's eth0.

    +
    +

    Last updated 3/21/2003 - Tom Eastep

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



    diff --git a/STABLE/documentation/SeattleInTheSpring.html b/STABLE/documentation/SeattleInTheSpring.html index d90ca36e6..a3207f8b3 100755 --- a/STABLE/documentation/SeattleInTheSpring.html +++ b/STABLE/documentation/SeattleInTheSpring.html @@ -1,52 +1,53 @@ - + Springtime in Seattle!!! - + - + - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Visit Seattle in the Springtime!!!!

    -
    - +

    - + +
    +
    + March 6, 2003 - Nice day for a walk....
    +
    +
    +

    - March 6, 2003 - Nice day for a walk....
    -
    - -
    -
    -
    - - -

    The view from my office window -- think I'll go out and enjoy the deck + + +

    The view from my office window -- think I'll go out and enjoy the deck (Yes -- that is snow on the deck...).
    -

    - -

    Updated 3/7/2003 - Tom Eastep +

    + +

    Updated 3/7/2003 - Tom Eastep

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.

    -
    +
    +

    diff --git a/STABLE/documentation/Shorewall_CA_html.html b/STABLE/documentation/Shorewall_CA_html.html index 712bece44..cd7d40ec9 100644 --- a/STABLE/documentation/Shorewall_CA_html.html +++ b/STABLE/documentation/Shorewall_CA_html.html @@ -2,91 +2,91 @@ Shorewall Certificate Authority - + - + - + - - - + + - - - + + + +
    - -

    Shorewall Certificate Authority + bgcolor="#3366ff" height="90"> +

    +

    Shorewall Certificate Authority (CA) Certificate

    -
    -
    - Given that I develop and support Shorewall without asking for any renumeration, - I can hardly justify paying $200US+ a year to a Certificate Authority such - as Thawte (A Division of VeriSign) for an X.509 certificate to prove that - I am who I am. I have therefore established my own Certificate Authority -(CA) and sign my own X.509 certificates. I use these certificates on my list -server (https://lists.shorewall.net) +
    + Given that I develop and support Shorewall without asking for any renumeration, + I can hardly justify paying $200US+ a year to a Certificate Authority such + as Thawte (A Division of VeriSign) for an X.509 certificate to prove that + I am who I am. I have therefore established my own Certificate Authority +(CA) and sign my own X.509 certificates. I use these certificates on my list +server (https://lists.shorewall.net) which hosts parts of this web site.
    -
    - X.509 certificates are the basis for the Secure Socket Layer (SSL). As -part of establishing an SSL session (URL https://...), your browser verifies -the X.509 certificate supplied by the HTTPS server against the set of Certificate - Authority Certificates that were shipped with your browser. It is expected - that the server's certificate was issued by one of the authorities whose +
    + X.509 certificates are the basis for the Secure Socket Layer (SSL). As +part of establishing an SSL session (URL https://...), your browser verifies +the X.509 certificate supplied by the HTTPS server against the set of Certificate + Authority Certificates that were shipped with your browser. It is expected + that the server's certificate was issued by one of the authorities whose identities are known to your browser.
    -
    - This mechanism, while supposedly guaranteeing that when you connect to -https://www.foo.bar you are REALLY connecting to www.foo.bar, means that -the CAs literally have a license to print money -- they are selling a string +
    + This mechanism, while supposedly guaranteeing that when you connect to +https://www.foo.bar you are REALLY connecting to www.foo.bar, means that +the CAs literally have a license to print money -- they are selling a string of bits (an X.509 certificate) for $200US+ per year!!!I
    -
    - I wish that I had decided to become a CA rather that designing and writing +
    + I wish that I had decided to become a CA rather that designing and writing Shorewall.
    -
    - What does this mean to you? It means that the X.509 certificate that my -server will present to your browser will not have been signed by one of the -authorities known to your browser. If you try to connect to my server using -SSL, your browser will frown and give you a dialog box asking if you want +
    + What does this mean to you? It means that the X.509 certificate that my +server will present to your browser will not have been signed by one of the +authorities known to your browser. If you try to connect to my server using +SSL, your browser will frown and give you a dialog box asking if you want to accept the sleezy X.509 certificate being presented by my server.
    -
    - There are two things that you can do:
    - +
    + There are two things that you can do:
    +
      -
    1. You can accept the mail.shorewall.net certificate when your browser - asks -- your acceptence of the certificate can be temporary (for that access +
    2. You can accept the mail.shorewall.net certificate when your browser + asks -- your acceptence of the certificate can be temporary (for that access only) or perminent.
      3. -
    3. You can download and install my (self-signed) CA -certificate. This will make my Certificate Authority known to your browser +
    4. You can download and install my (self-signed) CA +certificate. This will make my Certificate Authority known to your browser so that it will accept any certificate signed by me.
      -
      5. - + +
    - What are the risks?
    - + What are the risks?
    +
      -
    1. If you install my CA certificate then you assume that I am trustworthy - and that Shorewall running on your firewall won't redirect HTTPS requests - intented to go to your bank's server to one of my systems that will present -your browser with a bogus certificate claiming that my server is that of your -bank.
      2. -
    2. If you only accept my server's certificate when prompted then the -most that you have to loose is that when you connect to https://mail.shorewall.net, +
    3. If you install my CA certificate then you assume that I am trustworthy + and that Shorewall running on your firewall won't redirect HTTPS requests + intented to go to your bank's server to one of my systems that will present +your browser with a bogus certificate claiming that my server is that of +your bank.
      4. +
    4. If you only accept my server's certificate when prompted then the +most that you have to loose is that when you connect to https://mail.shorewall.net, the server you are connecting to might not be mine.
      5. - +
    - I have my CA certificate loaded into all of my browsers but I certainly + I have my CA certificate loaded into all of my browsers but I certainly won't be offended if you decline to load it into yours... :-)
    - +

    Last Updated 1/17/2003 - Tom Eastep

    - +

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

    + size="2">Copyright     © 2001, 2002, 2003 Thomas M. +Eastep.

    +



    diff --git a/STABLE/documentation/Shorewall_CVS_Access.html b/STABLE/documentation/Shorewall_CVS_Access.html index e9d6d819a..e8fd279e7 100644 --- a/STABLE/documentation/Shorewall_CVS_Access.html +++ b/STABLE/documentation/Shorewall_CVS_Access.html @@ -2,50 +2,51 @@ Shorewall CVS Access - + - + - + - - - + + - - - +
    + + + +
    -

    Shorewall CVS Access + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    +

    Shorewall CVS Access

    -
    -
    -
    - Lots of people try to download the entire Shorewall website for off-line - browsing, including the CVS portion. In addition to being an enormous volume - of data (HTML versions of all versions of all Shorewall files), all of -the pages in Shorewall CVS access are cgi-generated which places a tremendous - load on my little server. I have therefore resorted to making CVS access - password controlled. When you are asked to log in, enter "Shorewall" (NOTE +
    + Lots of people try to download the entire Shorewall website for off-line + browsing, including the CVS portion. In addition to being an enormous volume + of data (HTML versions of all versions of all Shorewall files), all of the + pages in Shorewall CVS access are cgi-generated which places a tremendous + load on my little server. I have therefore resorted to making CVS access + password controlled. When you are asked to log in, enter "Shorewall" (NOTE THE CAPITALIZATION!!!!!) for both the user name and the password.
    -
    - -
    +
    + +

    CVS Login  
    -

    -
    - -

    Updated 1/14/2002 - - Tom Eastep -

    - -

    Copyright + +

    + +

    Updated 1/14/2002 + - Tom Eastep +

    + +

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

    +



    diff --git a/STABLE/documentation/Shorewall_Squid_Usage.html b/STABLE/documentation/Shorewall_Squid_Usage.html index 61a732279..687edb8a9 100644 --- a/STABLE/documentation/Shorewall_Squid_Usage.html +++ b/STABLE/documentation/Shorewall_Squid_Usage.html @@ -2,530 +2,543 @@ Shorewall Squid Usage - + - + - + - - - - - - - - -
    -
    -     		Using Shorewall with Squid
    -     		-
    -
    -
    - This page covers Shorewall configuration to use with Squid running as a Transparent - Proxy. If you are running Shorewall 1.3, please see this documentation.
    -
    - Caution -     Please observe the following general requirements:
    -
    - -     In all cases, Squid should be configured -to run as a transparent proxy as described at http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html.
    -
    -     -     The following instructions mention the files - /etc/shorewall/start and /etc/shorewall/init -- if you don't have those - files, siimply create them.
    -
    - -     When the Squid server is in the DMZ zone -or in the local zone, that zone must be defined ONLY by its interface -- -no /etc/shorewall/hosts file entries. That is because the packets being -routed to the Squid server still have their original destination IP addresses.
    -
    - -     You must have iptables installed on your -Squid server.
    -
    - -     You must have NAT and MANGLE enabled in -your /etc/shorewall/conf file
    -
    -         NAT_ENABLED=Yes
    -             MANGLE_ENABLED=Yes
    -
    - Three different configurations are covered:
    - -
      -
    1. Squid running - on the Firewall.
      2. -
    2. Squid running in - the local network
      3. -
    3. Squid running in -the DMZ
      4. - -
    - -

    Squid Running on the Firewall

    - 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.
    -
    - In /etc/shorewall/rules:
    -
    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    REDIRECTloc3128tcpwww -
    -     		!206.124.146.177
    ACCEPTfwnettcpwww
    -
    -
    -
    -
    - There may be a requirement to exclude additional destination hosts -or networks from being redirected. For example, you might also want requests -destined for 130.252.100.0/24 to not be routed to Squid. In that case, you -must add a manual rule in /etc/shorewall/start:
    -
    - 
    run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN
    -
    - To exclude additional hosts or networks, just add additional similar -rules.
    -

    Squid Running in the local network

    - You want to redirect all local www connection requests to a -Squid transparent - proxy running in your local zone at 192.168.1.3 and listening on port - 3128. Your local interface is eth1. There may also be a web server running -on 192.168.1.3. It is assumed that web access is already enabled from the -local zone to the internet.
    - -

    WARNING: This setup may conflict with - other aspects of your gateway including but not limited to traffic shaping - and route redirection. For that reason, I don't recommend it.
    -

    - -
      -
    • On your firewall system, issue the following command
      -
      • - -
    - -
    - 
    echo 202 www.out >> /etc/iproute2/rt_tables
    -
    - -
      -
    • In /etc/shorewall/init, put:
      -
      • - -
    - -
    - 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.168.1.3 dev eth1 table www.out
    	ip route flush cache
    	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
    fi
    -
    - -
      -
    • If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, -please upgrade to Shorewall 1.4.2 or later.
      -
      -
      • -
    • If you are running Shorewall 1.4.2 or later, then in /etc/shorewall/interfaces:
      -
      - - - - - - - - - - - - - - - - - -
      ZONE
      -       		INTERFACE
      -       		BROADCAST
      -       		OPTIONS
      -
      loc
      -       		eth1
      -       		detect
      -       		routeback
      -
      -
      -
      • -
    • In /etc/shorewall/rules:
      -
      - - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
      ACCEPT
      -       		locloc
      -       		tcpwww
      -
      -
      -
      • -
      -
    • Alternativfely, if you are running Shorewall 1.4.0 you can have the -following policy in place of the above rule:
      - - + bgcolor="#3366ff"> - - - - - - - - - - - - + - - -
      SOURCE
      -       		DESTINATION
      -       		POLICY
      -       		LOG LEVEL
      -       		BURST PARAMETERS
      -
      loc
      +       		+
      		loc
      -       		ACCEPT
      -
      -
      +       		+

      Using Shorewall with Squid

      + +

      +       		+
      + + +
      -
      • -
    • In /etc/shorewall/start add:
      -
      • - -
    - -
    - 
    iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
    -
    - + This page covers Shorewall configuration to use with Squid running as a Transparent + Proxy. If you are running Shorewall 1.3, please see this documentation.
    +
    + Caution +     Please observe the following general requirements:
    +
    + +     In all cases, Squid should be configured + to run as a transparent proxy as described at http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html.
    +
    +     +     The following instructions mention the + files /etc/shorewall/start and /etc/shorewall/init -- if you don't have + those files, siimply create them.
    +
    + +     When the Squid server is in the DMZ +zone or in the local zone, that zone must be defined ONLY by its interface + -- no /etc/shorewall/hosts file entries. That is because the packets +being routed to the Squid server still have their original destination +IP addresses.
    +
    + +     You must have iptables installed on +your Squid server.
    +
    + +     If you run a Shorewall version earlier + than 1.4.6, you must have NAT and MANGLE enabled in your /etc/shorewall/conf + file
    +
    +         + NAT_ENABLED=Yes
    +             MANGLE_ENABLED=Yes
    +
    + Three different configurations are covered:
    + +
      +
    1. Squid running + on the Firewall.
      2. +
    2. Squid running + in the local network
      3. +
    3. Squid running + in the DMZ
      4. + +
    + +

    Squid Running on the Firewall

    + 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.
    +
    + In /etc/shorewall/rules:
    +
    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    REDIRECTloc3128tcpwww -
    +     		!206.124.146.177
    ACCEPTfwnettcpwww
    +
    +
    +
    +
    + There may be a requirement to exclude additional destination hosts + or networks from being redirected. For example, you might also want requests + destined for 130.252.100.0/24 to not be routed to Squid. In that case, you + must add a manual rule in /etc/shorewall/start:
    + +
    + 
    run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN
    +
    +  To exclude additional hosts or networks, just add additional similar + rules.
    + +

    Squid Running in the local network

    + You want to redirect all local www connection requests +to a Squid transparent + proxy running in your local zone at 192.168.1.3 and listening on +port 3128. Your local interface is eth1. There may also be a web server +running on 192.168.1.3. It is assumed that web access is already enabled +from the local zone to the internet.
    + +

    WARNING: This setup may conflict with + other aspects of your gateway including but not limited to traffic + shaping and route redirection. For that reason, I don't recommend + it.
    +

    +
      -
    • On 192.168.1.3, arrange for the following command to be executed - after networking has come up
      - - 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      -
      • - +
    • On your firewall system, issue the following command
      +
      • +
    - -
    If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
    -
    - -
    -
    - - 
    iptables-save > /etc/sysconfig/iptables
    chkconfig --level 35 iptables start
    -
    - -
    - -

    Squid Running in the DMZ (This is what I do)

    - You have a single Linux system in your DMZ with IP address 192.0.2.177. - You want to run both a web server and Squid on that system. Your DMZ interface - is eth1 and your local interface is eth2.
    - + +
    + 
    echo 202 www.out >> /etc/iproute2/rt_tables
    +
    +
      -
    • On your firewall system, issue the following command
      -
      • - +
    • In /etc/shorewall/init, put:
      +
      • +
    - -
    - 
    echo 202 www.out >> /etc/iproute2/rt_tables
    -
    - + +
    + 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.168.1.3 dev eth1 table www.out
    	ip route flush cache
    	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
    fi
    +
    +
      -
    • In /etc/shorewall/init, put:
      -
      • - -
    - -
    - 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.0.2.177 dev eth1 table www.out
    	ip route flush cache
    fi
    -
    - -
      -
    •  Do one of the following:
      +
    • If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, + please upgrade to Shorewall 1.4.2 or later.

      - A) In /etc/shorewall/start add
      -
      • - -
    - -
    - 
    	iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
    -
    - -
    B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf - and add the following entry in /etc/shorewall/tcrules:
    -
    - -
    -
    - - - - - - - - - - - - - - - - - - - - -
    MARK
    -     		SOURCE
    -     		DESTINATION
    -     		PROTOCOL
    -     		PORT
    -     		CLIENT PORT
    -
    202
    -     		eth2
    -     		0.0.0.0/0
    -     		tcp
    -     		80
    -     		-
    -
    -
    - C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
    -
    - -
    -
    - - - - - - - - - - - - - - - - - - - - -
    MARK
    -     		SOURCE
    -     		DESTINATION
    -     		PROTOCOL
    -     		PORT
    -     		CLIENT PORT
    -
    202:P
    -     		eth2
    -     		0.0.0.0/0
    -     		tcp
    -     		80
    -     		-
    -
    -
    -
    - -
      -
    • In /etc/shorewall/rules, you will need:
      • - -
    - -
    - + +
  • If you are running Shorewall 1.4.2 or later, then in /etc/shorewall/interfaces:
    +
    + +
    • - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTION
    +     		ZONE
    		SOURCE
    +     		INTERFACE
    		DEST
    +     		BROADCAST
    		PROTO
    -     		DEST
    - PORT(S)
    -     		CLIENT
    - PORT(2)
    -     		ORIGINAL
    - DEST
    +     		OPTIONS
    ACCEPT
    -     		loc
    -     		dmz
    -     		tcp
    -     		80
    -
    -
    -
    ACCEPT
    +     		loc
    		dmz
    +     		eth1
    		net
    +     		detect
    		tcp
    -     		80
    -
    -
    +     		routeback
    -
    -
    - -
      -
    • On 192.0.2.177 (your Web/Squid server), arrange for the -following command to be executed after networking has come up
      - - 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      -
      • - + + + +
      + +
    • In /etc/shorewall/rules:
      +
      + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      ACCEPT
      +       		locloc
      +       		tcpwww
      +
      +
      +
      • +
      +
    • Alternativfely, if you are running Shorewall 1.4.0 you can have + the following policy in place of the above rule:
      + + + + + + + + + + + + + + + + + + + +
      SOURCE
      +       		DESTINATION
      +       		POLICY
      +       		LOG LEVEL
      +       		BURST PARAMETERS
      +
      loc
      +       		loc
      +       		ACCEPT
      +
      +
      +
      +
      +
      • +
    • In /etc/shorewall/start add:
      +
      • +
    - -
    If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
    -
    - -
    + +
    + 
    iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
    +
    + +
      +
    • On 192.168.1.3, arrange for the following command to +be executed after networking has come up
      + + 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      +
      • + +
    + +
    If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command +above:
    +
    + +
    - + 
    iptables-save > /etc/sysconfig/iptables
    chkconfig --level 35 iptables start
    -
    - + color="#009900">
    chkconfig --level 35 iptables on
     +
    +
    - -

    Updated 5/29/2003 - Tom Eastep -

    + +

    Squid Running in the DMZ (This is what I do)

    + You have a single Linux system in your DMZ with IP address + 192.0.2.177. You want to run both a web server and Squid on that system. + Your DMZ interface is eth1 and your local interface is eth2.
    + +
      +
    • On your firewall system, issue the following command
      +
      • + +
    + +
    + 
    echo 202 www.out >> /etc/iproute2/rt_tables
    +
    + +
      +
    • In /etc/shorewall/init, put:
      +
      • + +
    + +
    + 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.0.2.177 dev eth1 table www.out
    	ip route flush cache
    fi
    +
    + +
      +
    •  Do one of the following:
      +
      + A) In /etc/shorewall/start add
      +
      • + +
    + +
    + 
    	iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
    +
    + +
    B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf + and add the following entry in /etc/shorewall/tcrules:
    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + +
    MARK
    +     		SOURCE
    +     		DESTINATION
    +     		PROTOCOL
    +     		PORT
    +     		CLIENT PORT
    +
    202
    +     		eth2
    +     		0.0.0.0/0
    +     		tcp
    +     		80
    +     		-
    +
    +
    + C) Run Shorewall 1.3.14 or later and add the following entry in + /etc/shorewall/tcrules:
    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + +
    MARK
    +     		SOURCE
    +     		DESTINATION
    +     		PROTOCOL
    +     		PORT
    +     		CLIENT PORT
    +
    202:P
    +     		eth2
    +     		0.0.0.0/0
    +     		tcp
    +     		80
    +     		-
    +
    +
    +
    + +
      +
    • In /etc/shorewall/rules, you will need:
      • + +
    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTION
    +     		SOURCE
    +     		DEST
    +     		PROTO
    +     		DEST
    + PORT(S)
    +     		CLIENT
    + PORT(2)
    +     		ORIGINAL
    + DEST
    +
    ACCEPT
    +     		loc
    +     		dmz
    +     		tcp
    +     		80
    +
    +
    +
    ACCEPT
    +     		dmz
    +     		net
    +     		tcp
    +     		80
    +
    +
    +
    +
    +
    + +
      +
    • On 192.0.2.177 (your Web/Squid server), arrange for +the following command to be executed after networking has come up
      + + 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      +
      • + +
    + +
    If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command +above:
    +
    + +
    +
    + + 
    iptables-save > /etc/sysconfig/iptables
    chkconfig --level 35 iptables on
    +
    + +
    + +

    Updated 7/18/2003 - Tom Eastep +

    - Copyright © - 2003 Thomas M. Eastep.
    -
    -
    + Copyright + © 2003 Thomas M. Eastep.
    +
    +
    +
    diff --git a/STABLE/documentation/Shorewall_and_Aliased_Interfaces.html b/STABLE/documentation/Shorewall_and_Aliased_Interfaces.html index e5f576ad1..c4716d30d 100755 --- a/STABLE/documentation/Shorewall_and_Aliased_Interfaces.html +++ b/STABLE/documentation/Shorewall_and_Aliased_Interfaces.html @@ -2,622 +2,652 @@ Shorewall and Aliased Interfaces - + - + - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +
    +

    Shorewall and Aliased Interfaces

    -
    -
    - +
    +

    Background

    - The traditional net-tools contain a program called ifconfig -which is used to configure network devices. ifconfig introduced the concept -of aliased or virtial interfaces. These virtual interfaces -have names of the form interface:integer (e.g., eth0:0) and -ifconfig treats them more or less like real interfaces.
    -
    - Example:
    - + The traditional net-tools contain a program called ifconfig + which is used to configure network devices. ifconfig introduced the concept + of aliased or virtial interfaces. These virtual interfaces + have names of the form interface:integer (e.g., eth0:0) +and ifconfig treats them more or less like real interfaces.
    +
    + Example:
    + 
    [root@gateway root]# ifconfig eth0:0
    eth0:0    Link encap:Ethernet  HWaddr 02:00:08:3:FA:55
              inet addr:206.124.146.178  Bcast:206.124.146.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              Interrupt:11 Base address:0x2000
    [root@gateway root]#
    - The ifconfig utility is being gradually phased out in favor of the ip - utility which is part of the iproute package. The ip utility does - not use the concept of aliases or virtual interfaces but rather treats + The ifconfig utility is being gradually phased out in favor of the +ip utility which is part of the iproute package. The ip utility +does not use the concept of aliases or virtual interfaces but rather treats additional addresses on an interface as objects. The ip utility does provide for interaction with ifconfig in that it allows addresses to be labeled and labels may take the form of ipconfig virtual interfaces.
    -
    - Example:
    -
    - +
    + Example:
    +
    + 
    [root@gateway root]# ip addr show dev 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:0
    [root@gateway root]#
    - Note that one cannot type "ip addr show dev eth0:0" because -"eth0:0" is a label for a particular address rather than a device name.
    - + Note that one cannot type "ip addr show dev eth0:0" because + "eth0:0" is a label for a particular address rather than a device name.
    + 
    [root@gateway root]# ip addr show dev eth0:0
    Device "eth0:0" does not exist.
    [root@gateway root]#
    - The iptables program doesn't support virtual interfaces in either it's - "-i" or "-o" command options; as a consequence, Shorewall does not allow - them to be used in the /etc/shorewall/interfaces file.
    -
    - + The iptables program doesn't support virtual interfaces in either +it's "-i" or "-o" command options; as a consequence, Shorewall does not +allow them to be used in the /etc/shorewall/interfaces file.
    +
    +

    So how do I handle more than one address on an interface?

    - The answer depends on what you are trying to do with the interfaces. - In the sub-sections that follow, we'll take a look at common scenarios.
    - + The answer depends on what you are trying to do with the interfaces. + In the sub-sections that follow, we'll take a look at common scenarios.
    +

    Separate Rules

    - If you need to make a rule for traffic to/from the firewall itself that - only applies to a particular IP address, simply qualify the $FW zone with - the IP address.
    -
    - Example (allow SSH from net to eth0:0 above):
    -
    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ACTION
    -     		SOURCE
    -     		DESTINATION
    -     		PROTOCOL
    -     		PORT(S)
    -     		SOURCE PORT(S)
    -     		ORIGINAL DESTINATION
    -
    ACCEPT
    -     		net
    -     		fw:206.124.146.178
    -     		tcp
    -     		22
    -
    -
    -
    + If you need to make a rule for traffic to/from the firewall itself +that only applies to a particular IP address, simply qualify the $FW zone +with the IP address.

    -
    - -

    DNAT

    - Suppose that I had set up eth0:0 as above and I wanted to port forward - from that virtual interface to a web server running in my local zone at - 192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules - file:
    -
    - -
    + Example (allow SSH from net to eth0:0 above):
    +
    + +
    - - - - - - - - - - - - - - - - - - - - - -
    ACTION
    -     		SOURCE
    -     		DESTINATION
    -     		PROTOCOL
    -     		PORT(S)
    -     		SOURCE PORT(S)
    -     		ORIGINAL DESTINATION
    -
    DNAT
    -     		net
    -     		loc:192.168.1.3
    -     		tcp
    -     		80
    -     		-
    -     		206.124.146.178
    -
    -
    -
    - -

    SNAT

    - If you wanted to use eth0:0 as the IP address for outbound connections - from your local zone (eth1), then in /etc/shorewall/masq:
    -
    - -
    - - - - - - - - - - - - - - -
    INTERFACE
    -     		SUBNET
    -     		ADDRESS
    -
    eth0
    -     		eth1
    -     		206.124.146.178
    -
    -
    -
    - Shorewall can create the alias (additional address) for you if you -set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with -Shorewall 1.3.14, Shorewall can actually create the "label" (virtual interface) -so that you can see the created address using ifconfig. In addition to -setting ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in -the INTERFACE column as follows:
    - -
    - - - - - - - - - + + + + + + + + + + + + + + + + - - - - - + + +
    INTERFACE
    -     		SUBNET
    -     		ADDRESS
    -
    eth0:0
    +
    ACTION
    +     		SOURCE
    +     		DESTINATION
    +     		PROTOCOL
    +     		PORT(S)
    +     		SOURCE PORT(S)
    +     		ORIGINAL DESTINATION
    +
    ACCEPT
    +     		net
    +     		fw:206.124.146.178
    +     		tcp
    +     		22
    +
    		eth1
    +
    		206.124.146.178
    -

    - -

    STATIC NAT

    - If you wanted to use static NAT to link eth0:0 with local address 192.168.1.3, - you would have the following in /etc/shorewall/nat:
    -
    - -
    - - - - - - - - - - - - - - - - - - -
    EXTERNAL
    -     		INTERFACE
    -     		INTERNAL
    -     		ALL INTERFACES
    -     		LOCAL
    -
    206.124.146.178
    -     		eth0
    -     		192.168.1.3
    -     		no
    -     		no
    -
    + +

    DNAT

    + Suppose that I had set up eth0:0 as above and I wanted to port forward + from that virtual interface to a web server running in my local zone +at 192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules + file:

    -
    - Shorewall can create the alias (additional address) for you if you -set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with -Shorewall 1.3.14, Shorewall can actually create the "label" (virtual interface) -so that you can see the created address using ifconfig. In addition to -setting ADD_IP_ALIASES=Yes, you specify the virtual interface name in -the INTERFACE column as follows:
    -
    - -
    - - - - - - - - - - - - - - - - - - -
    EXTERNAL
    -     		INTERFACE
    -     		INTERNAL
    -     		ALL INTERFACES
    -     		LOCAL
    -
    206.124.146.178
    -     		eth0:0
    -     		192.168.1.3
    -     		no
    -     		no
    -
    -
    -
    - In either case, to create rules that pertain only to this NAT pair, -you simply qualify the local zone with the internal IP address.
    -
    - Example: You want to allow SSH from the net to 206.124.146.178 a.k.a. - 192.168.1.3.
    -
    - -
    + +
    - - - - - - - - - - - - - - - - - - - - - -
    ACTION
    -     		SOURCE
    -     		DESTINATION
    -     		PROTOCOL
    -     		PORT(S)
    -     		SOURCE PORT(S)
    -     		ORIGINAL DESTINATION
    -
    ACCEPT
    -     		net
    -     		loc:192.168.1.3
    -     		tcp
    -     		22
    -
    -
    -
    -
    -
    - -

    MULTIPLE SUBNETS

    - Sometimes multiple IP addresses are used because there are multiple -subnetworks configured on a LAN segment. This technique does not provide -for any security between the subnetworks if the users of the systems have -administrative privileges because in that case, the users can simply manipulate -their system's routing table to bypass your firewall/router. Nevertheless, -there are cases where you simply want to consider the LAN segment itself -as a zone and allow your firewall/router to route between the two subnetworks.
    -
    - Example 1:  Local interface eth1 interfaces to 192.168.1.0/24 -and 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and -eth1:0 is 192.168.20.254. You want to simply route all requests between -the two subnetworks.
    - -

    If you are running Shorewall 1.4.1 or Later

    - In /etc/shorewall/interfaces:
    - -
    - - - - - - - - - - - - - - - - -
    ZONE
    -     		INTERFACE
    -     		BROADCAST
    -     		OPTIONS
    -
    -
    -     		eth1
    -     		192.168.1.255,192.168.20.255
    -
    -
    -
    -
    - In /etc/shorewall/hosts:
    - -
    - - - - - - - - - - - - - - - - - - - -
    ZONE
    -     		HOSTS
    -     		OPTIONS
    -
    loc
    -     		eth1:192.168.1.0/24
    -
    -
    loc
    -     		eth1:192.168.20.0/24
    -
    -
    -
    -
    - Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall - 1.4.1 and later releases default to allowing intra-zone traffic.
    - -

    If you are running Shorewall 1.4.0 or earlier
    -

    - In /etc/shorewall/interfaces:
    -
    - -
    - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ZONE
    -     		INTERFACE
    -     		BROADCAST
    -     		OPTIONS
    -
    loc
    -     		eth1
    -     		192.168.1.255,192.168.20.255
    -     		Note 1:
    -
    ACTION
    +     		SOURCE
    +     		DESTINATION
    +     		PROTOCOL
    +     		PORT(S)
    +     		SOURCE PORT(S)
    +     		ORIGINAL DESTINATION
    +
    DNAT
    +     		net
    +     		loc:192.168.1.3
    +     		tcp
    +     		80
    +     		-
    +     		206.124.146.178
    +
    +
    +
    + +

    SNAT

    + If you wanted to use eth0:0 as the IP address for outbound connections + from your local zone (eth1), then in /etc/shorewall/masq:

    -
    - Note 1: If you are running Shorewall 1.3.10 or earlier then you must - specify the multi option.
    -
    - In /etc/shorewall/policy:
    -
    - -
    + +
    - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    SOURCE
    -     		DESTINATION
    -     		POLICY
    -     		LOG LEVEL
    -     		BURST:LIMIT
    -
    loc
    -     		loc
    -     		ACCEPT
    -
    -
    -
    INTERFACE
    +     		SUBNET
    +     		ADDRESS
    +
    eth0
    +     		eth1
    +     		206.124.146.178
    +
    +
    +
    + Shorewall can create the alias (additional address) for you if you + set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning +with Shorewall 1.3.14, Shorewall can actually create the "label" (virtual +interface) so that you can see the created address using ifconfig. In +addition to setting ADD_SNAT_ALIASES=Yes, you specify the virtual interface +name in the INTERFACE column as follows:
    + +
    + + + + + + + + + + + + + + +
    INTERFACE
    +     		SUBNET
    +     		ADDRESS
    +
    eth0:0
    +     		eth1
    +     		206.124.146.178
    +
    +
    + Shorewall can also set up SNAT to round-robin over a range of IP addresses. +Do do that, you specify a range of IP addresses in the ADDRESS column. If +you specify a label in the INTERFACE column, Shorewall will use that label +for the first address of the range and will increment the label by one for +each subsequent label.
    +
    + +
    + + + + + + + + + + + + + + +
    INTERFACE
    +     		SUBNET
    +     		ADDRESS
    +
    eth0:0
    +     		eth1
    +     		206.124.146.178-206.124.146.180
    +
    +
    + The above would create three IP addresses:
    +
    +     eth0:0 = 206.124.146.178
    +     eth0:1 = 206.124.146.179
    +     eth0:2 = 206.124.146.180
    + +

    STATIC NAT

    + If you wanted to use static NAT to link eth0:0 with local address +192.168.1.3, you would have the following in /etc/shorewall/nat:

    -
    - Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and 192.168.20.0/24. - The primary IP address of eth1 is 192.168.1.254 and eth1:0 is 192.168.20.254. - You want to make these subnetworks into separate zones and control the -access between them (the users of the systems do not have administrative -privileges).
    -
    - In /etc/shorewall/zones:
    -
    - -
    + +
    - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    ZONE
    -     		DISPLAY
    -     		DESCRIPTION
    -
    loc
    -     		Local
    -     		Local Zone 1
    -
    loc2
    -     		Local2
    -     		Local Zone 2
    -
    EXTERNAL
    +     		INTERFACE
    +     		INTERNAL
    +     		ALL INTERFACES
    +     		LOCAL
    +
    206.124.146.178
    +     		eth0
    +     		192.168.1.3
    +     		no
    +     		no
    +
    +
    +
    + Shorewall can create the alias (additional address) for you if you + set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with + Shorewall 1.3.14, Shorewall can actually create the "label" (virtual +interface) so that you can see the created address using ifconfig. In +addition to setting ADD_IP_ALIASES=Yes, you specify the virtual interface +name in the INTERFACE column as follows:

    -
    - In /etc/shorewall/interfaces:
    -
    - -
    + +
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    ZONE
    -     		INTERFACE
    -     		BROADCAST
    -     		OPTIONS
    -
    -
    -     		eth1
    -     		192.168.1.255,192.168.20.255
    -     		Note 1:
    -
    EXTERNAL
    +     		INTERFACE
    +     		INTERNAL
    +     		ALL INTERFACES
    +     		LOCAL
    +
    206.124.146.178
    +     		eth0:0
    +     		192.168.1.3
    +     		no
    +     		no
    +
    +
    +
    + In either case, to create rules that pertain only to this NAT pair, + you simply qualify the local zone with the internal IP address.

    -
    - Note 1: If you are running Shorewall 1.3.10 or earlier then you must - specify the multi option.
    -
    - In /etc/shorewall/hosts:
    - -
    - - - - - - - - -
    ZONE
    -     		HOSTS
    -     		OPTIONS
    -
    loc
    + Example: You want to allow SSH from the net to 206.124.146.178 a.k.a. + 192.168.1.3.
    +
    + +
    + + + + + + + + + + + + + + + + + + - - - - - - - - - - + + +
    ACTION
    +     		SOURCE
    +     		DESTINATION
    +     		PROTOCOL
    +     		PORT(S)
    +     		SOURCE PORT(S)
    +     		ORIGINAL DESTINATION
    +
    ACCEPT
    +     		net
    +     		loc:192.168.1.3
    +     		tcp
    +     		22
    +
    		eth1:192.168.1.0/24
    +

    -
    loc2
    -     		eth1:192.168.20.0/24
    -
    -
    -
    -
    - In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic - that you want to permit.
    -
    - -

    Last Updated 5/8/2003 A - Tom Eastep

    - -

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


    + + +

    MULTIPLE SUBNETS

    + Sometimes multiple IP addresses are used because there are multiple + subnetworks configured on a LAN segment. This technique does not provide + for any security between the subnetworks if the users of the systems have + administrative privileges because in that case, the users can simply manipulate + their system's routing table to bypass your firewall/router. Nevertheless, + there are cases where you simply want to consider the LAN segment itself + as a zone and allow your firewall/router to route between the two subnetworks.
    +
    + Example 1:  Local interface eth1 interfaces to 192.168.1.0/24 + and 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 +and eth1:0 is 192.168.20.254. You want to simply route all requests between + the two subnetworks.
    + +

    If you are running Shorewall 1.4.1 or Later

    + In /etc/shorewall/interfaces:
    + +
    + + + + + + + + + + + + + + + + +
    ZONE
    +     		INTERFACE
    +     		BROADCAST
    +     		OPTIONS
    +
    -
    +     		eth1
    +     		192.168.1.255,192.168.20.255
    +
    +

    -
    -
    +
    + In /etc/shorewall/hosts:
    + +
    + + + + + + + + + + + + + + + + + + + +
    ZONE
    +     		HOSTS
    +     		OPTIONS
    +
    loc
    +     		eth1:192.168.1.0/24
    +
    +
    loc
    +     		eth1:192.168.20.0/24
    +
    +
    +
    +
    + Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall + 1.4.1 and later releases default to allowing intra-zone traffic.
    + +

    If you are running Shorewall 1.4.0 or earlier
    +

    + In /etc/shorewall/interfaces:
    +
    + +
    + + + + + + + + + + + + + + + + +
    ZONE
    +     		INTERFACE
    +     		BROADCAST
    +     		OPTIONS
    +
    loc
    +     		eth1
    +     		192.168.1.255,192.168.20.255
    +     		Note 1:
    +
    +
    +
    + Note 1: If you are running Shorewall 1.3.10 or earlier then you must + specify the multi option.
    +
    + In /etc/shorewall/policy:
    +
    + +
    + + + + + + + + + + + + + + + + + + +
    SOURCE
    +     		DESTINATION
    +     		POLICY
    +     		LOG LEVEL
    +     		BURST:LIMIT
    +
    loc
    +     		loc
    +     		ACCEPT
    +
    +
    +
    +
    +
    + Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and +192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and +eth1:0 is 192.168.20.254. You want to make these subnetworks into separate +zones and control the access between them (the users of the systems do +not have administrative privileges).
    +
    + In /etc/shorewall/zones:
    +
    + +
    + + + + + + + + + + + + + + + + + + + +
    ZONE
    +     		DISPLAY
    +     		DESCRIPTION
    +
    loc
    +     		Local
    +     		Local Zone 1
    +
    loc2
    +     		Local2
    +     		Local Zone 2
    +
    +
    +
    + In /etc/shorewall/interfaces:
    +
    + +
    + + + + + + + + + + + + + + + + +
    ZONE
    +     		INTERFACE
    +     		BROADCAST
    +     		OPTIONS
    +
    -
    +     		eth1
    +     		192.168.1.255,192.168.20.255
    +     		Note 1:
    +
    +
    +
    + Note 1: If you are running Shorewall 1.3.10 or earlier then you must + specify the multi option.
    +
    + In /etc/shorewall/hosts:
    + +
    + + + + + + + + + + + + + + + + + + + +
    ZONE
    +     		HOSTS
    +     		OPTIONS
    +
    loc
    +     		eth1:192.168.1.0/24
    +
    +
    loc2
    +     		eth1:192.168.20.0/24
    +
    +
    +
    +
    + In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic + that you want to permit.
    +
    + +

    Last Updated 6/22/2003 A - Tom Eastep

    + +

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


    diff --git a/STABLE/documentation/Shorewall_index_frame.htm b/STABLE/documentation/Shorewall_index_frame.htm index 97f753f49..397a2515f 100644 --- a/STABLE/documentation/Shorewall_index_frame.htm +++ b/STABLE/documentation/Shorewall_index_frame.htm @@ -1,138 +1,145 @@ - + - + - + - + Shorewall Index - - + - + - - - + + - - - + + + - - - + + + +
    - + bgcolor="#3366ff" height="90"> +
    + +

    Shorewall

    -
    - +
    + + - + + -
    - +

    Copyright © 2001-2003 Thomas M. Eastep.

    diff --git a/STABLE/documentation/Shorewall_sfindex_frame.htm b/STABLE/documentation/Shorewall_sfindex_frame.htm index 4a2d44d7e..11f6fbfe3 100644 --- a/STABLE/documentation/Shorewall_sfindex_frame.htm +++ b/STABLE/documentation/Shorewall_sfindex_frame.htm @@ -1,138 +1,142 @@ - + - + - + - + Shorewall Index - - + - + - - - + + - - - + + + - - - + + + +
    - + bgcolor="#3366ff" height="90"> +
    + +

    Shorewall

    -
    - +
    + + - + -
    - +

    Copyright © 2001-2003 Thomas M. Eastep.

    diff --git a/STABLE/documentation/VPN.htm b/STABLE/documentation/VPN.htm index 29c2cf414..334005fb6 100644 --- a/STABLE/documentation/VPN.htm +++ b/STABLE/documentation/VPN.htm @@ -1,104 +1,106 @@ - + - + - + - + VPN - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

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

    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:

    - -
    +

    + +

    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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCLIENT
    - PORT    		ORIGINAL
    - DEST
    DNATnet:192.0.2.224loc:192.168.1.1250   
    DNATnet:192.0.2.224loc:192.168.1.12udp500  
    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. +

    + +

    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 + href="http://www.shorewall.net/Documentation.htm#Tunnels"> http://www.shorewall.net/Documentation.htm#Tunnels or http://www.shorewall.net/PPTP.htm.

    - +

    Last modified 12/21/2002 - Tom Eastep

    -

    Copyright + +

    Copyright © 2002 Thomas M. Eastep.

    +

     

    -
    +
    +
    diff --git a/STABLE/documentation/blacklisting_support.htm b/STABLE/documentation/blacklisting_support.htm index cd091bcd4..c92e034b0 100644 --- a/STABLE/documentation/blacklisting_support.htm +++ b/STABLE/documentation/blacklisting_support.htm @@ -1,98 +1,98 @@ - + - + - + - + Blacklisting Support - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Blacklisting Support

    -
    - +

    Shorewall supports two different forms of blacklisting; static and dynamic.

    - +

    Static Blacklisting

    - -

    Shorewall static blacklisting support has the following configuration -parameters:

    - + +

    Shorewall static blacklisting support has the following configuration parameters:

    +
      -
    • You specify whether you want packets from blacklisted hosts dropped - or rejected using the BLACKLIST_DISPOSITION +
    • 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 +
    • You specify whether you want packets from blacklisted hosts logged and at what syslog level using the BLACKLIST_LOGLEVEL setting in + href="Documentation.htm#BLLoglevel">BLACKLIST_LOGLEVEL setting in /etc/shorewall/shorewall.conf
      • -
    • You list the IP addresses/subnets that you wish to blacklist in - /etc/shorewall/blacklist. Beginning - with Shorewall version 1.3.8, you may also specify PROTOCOL and Port numbers/Service +
    • You list the IP addresses/subnets that you wish to blacklist in + /etc/shorewall/blacklist. Beginning + with Shorewall version 1.3.8, you may also specify PROTOCOL and Port numbers/Service names in the blacklist file.
      -
      • -
    • You specify the interfaces whose incoming packets you want checked +
      • +
    • You specify the interfaces whose incoming packets you want checked against the blacklist using the "blacklist" option in /etc/shorewall/interfaces.
      • -
    • The black list is refreshed from /etc/shorewall/blacklist by the +
    • The black list is refreshed from /etc/shorewall/blacklist by the "shorewall refresh" command.
      • - +
    - +

    Dynamic Blacklisting

    - -

    Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting - doesn't use any configuration parameters but is rather controlled using + +

    Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting + doesn't use any configuration parameters but is rather controlled using /sbin/shorewall commands:

    - +
      -
    • drop <ip address list> - causes packets from the listed +
    • drop <ip address list> - causes packets from the listed IP addresses to be silently dropped by the firewall.
      • -
    • reject <ip address list> - causes packets from the +
    • reject <ip address list> - causes packets from the listed IP addresses to be rejected by the firewall.
      • -
    • allow <ip address list> - re-enables receipt of packets +
    • allow <ip address list> - re-enables receipt of packets from hosts previously blacklisted by a deny or reject command.
      • -
    • save - save the dynamic blacklisting configuration so that it will +
    • save - save the dynamic blacklisting configuration so that it will be automatically restored the next time that the firewall is restarted.
      • -
    • show dynamic - displays the dynamic blacklisting configuration.
      • - +
    • show dynamic - displays the dynamic blacklisting configuration.
      • +
    -Dynamic blacklisting is not dependent on the "blacklist" option in + Dynamic blacklisting is not dependent on the "blacklist" option in /etc/shorewall/interfaces.
    - +

    Example 1:

    - + 
         shorewall drop 192.0.2.124 192.0.2.125
    - +

        Drops packets from hosts 192.0.2.124 and 192.0.2.125

    - +

    Example 2:

    - + 
         shorewall allow 192.0.2.125
    - +

        Reenables access from 192.0.2.125.

    - +

    Last updated 2/7/2003 - Tom Eastep

    - -

    Copyright + +

    Copyright © 2002, 2003 Thomas M. Eastep.

    -
    +
    +


    diff --git a/STABLE/documentation/configuration_file_basics.htm b/STABLE/documentation/configuration_file_basics.htm index f9f0bf69e..96228e31f 100644 --- a/STABLE/documentation/configuration_file_basics.htm +++ b/STABLE/documentation/configuration_file_basics.htm @@ -1,407 +1,409 @@ - + - + - + - + Configuration File Basics - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Configuration Files

    -
    - +

    Warning: If you copy or edit your configuration -files on a system running Microsoft Windows, you must - run them through 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/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".
      • -
    • /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN -- RFC 3168) to remote hosts or networks.
      -
      • - +
    • /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".
      • +
    • /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN + - RFC 3168) to remote hosts or networks.
      +
      • +
    - +

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

    - + ("\") followed immediately by a new line character.

    +

    Example:

    - + 
    ACCEPT	net	fw	tcp \
    smtp,www,pop3,imap  #Services running on the firewall
    - +

    INCLUDE Directive

    - Beginning with Shorewall version 1.4.2, any file may contain INCLUDE directives. -An INCLUDE directive consists of the word INCLUDE followed by a file name -and causes the contents of the named file to be logically included into -the file containing the INCLUDE. File names given in an INCLUDE directive -are assumed to reside in /etc/shorewall or in an alternate configuration -directory if one has been specified for the command.
    -
    -INCLUDE's may be nested to a level of 3 -- further nested INCLUDE directives - are ignored with a warning message.
    -
    -     Examples:
    - + Beginning with Shorewall version 1.4.2, any file may contain INCLUDE directives. + An INCLUDE directive consists of the word INCLUDE followed by a file name + and causes the contents of the named file to be logically included into + the file containing the INCLUDE. File names given in an INCLUDE directive + are assumed to reside in /etc/shorewall or in an alternate configuration + directory if one has been specified for the command.
    +
    + INCLUDE's may be nested to a level of 3 -- further nested INCLUDE directives + are ignored with a warning message.
    +
    +     Examples:
    +
       shorewall/params.mgmt:
    - +
       MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
    -    TIME_SERVERS=4.4.4.4
    -    BACKUP_SERVERS=5.5.5.5
    +    TIME_SERVERS=4.4.4.4
    +    BACKUP_SERVERS=5.5.5.5
    +
    +    ----- end params.mgmt -----
    -    ----- end params.mgmt -----
    - - +
       shorewall/params:
    -
    - -
    +
    + +
       # Shorewall 1.3 /etc/shorewall/params
    -    [..]
    -    #######################################
    -  
    -    INCLUDE params.mgmt   
    -  
    -    # params unique to this host here
    -    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +    [..]
    +    #######################################
    +  
    +    INCLUDE params.mgmt   
    +  
    +    # params unique to this host here
    +    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +
    - - +
       ----- end params -----
    -
    - + +
       shorewall/rules.mgmt:
    -
    - -
    +
    + +
       ACCEPT net:$MGMT_SERVERS          $FW    tcp    22
    -    ACCEPT $FW          net:$TIME_SERVERS    udp    123
    -    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    22
    +    ACCEPT $FW          net:$TIME_SERVERS    udp    123
    +    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    22
    +
    - - +
       ----- end rules.mgmt -----
    -
    - -
       shorewall/rules:
    -
    - -
    -
       # Shorewall version 1.3 - Rules File
    -    [..]
    -    #######################################
    -  
    -    INCLUDE rules.mgmt    
    -  
    -    # rules unique to this host here
    -    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - + +
       shorewall/rules:
    +
    + +
    +
       # Shorewall version 1.3 - Rules File
    +    [..]
    +    #######################################
    +  
    +    INCLUDE rules.mgmt    
    +  
    +    # rules unique to this host here
    +    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    +
    +
    +
       ----- end rules -----
    -
    + +

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

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

    - +

    + +

    Beginning with Shorewall 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 +
    • If your /etc/resolv.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.
      -
      • - +
    • 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:
    -

    - + 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).
      • - +
    • mail.shorewall.net
      • +
    • shorewall.net. (note the trailing period).
      • +
    - Examples of invalid DNS names:
    - + Examples of invalid DNS names:
    +
      -
    • mail (not fully qualified)
      • -
    • shorewall.net (only one period)
      • - +
    • mail (not fully qualified)
      • +
    • shorewall.net (only one period)
      • +
    - DNS names may not be used as:
    - + 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.
      • - +
    • 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.
    - + 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 "!".

    - + 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: routefilter,dhcp,norfc1918
      - Invalid: routefilter,     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: routefilter,dhcp,norfc1918
      + Invalid: routefilter,     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.

    - + 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
    - If you omit the low port number, a value of zero is assumed; if you omit - the high port number, a value of 65535 is assumed.
    - + If you omit the low port number, a value of zero is assumed; if you +omit the high port number, a value of 65535 is assumed.
    +

    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=routefilter,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 routefilter,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".
    -

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

    +

    Note: It is not necessary to use the special Shorewall notation - in the /etc/shorewall/maclist file.
    -

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

    - + The shorewall check, +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:

    - + 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. - +
    4. copying the files that need modification + from /etc/shorewall to a separate directory;
      5. +
    5. modify those files in the separate directory; + and
      6. +
    6. specifying the separate directory in a +shorewall start or shorewall restart command (e.g., shorewall +-c /etc/testconfig restart )
      7. +
    - -

    Updated 4/18/2003 - Tom Eastep -

    - + The try command +allows you to attempt to restart using an alternate configuration and if an +error occurs to automatically restart the standard configuration.
    + +

    Updated 6/29/2003 - Tom Eastep +

    +

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

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


    diff --git a/STABLE/documentation/copyright.htm b/STABLE/documentation/copyright.htm index 387a1a254..b18869cfe 100644 --- a/STABLE/documentation/copyright.htm +++ b/STABLE/documentation/copyright.htm @@ -1,45 +1,46 @@ - + - + - + - + Copyright - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Copyright

    -
    - -

    Copyright ©  2000, 2001, + +

    Copyright ©  2000, 2001, 2003 Thomas M Eastep
    -  

    - -
    -

    Permission is granted to copy, distribute and/or modify -this document under the terms of the GNU Free Documentation License, Version -1.1 or any later version published by the Free Software Foundation; with -no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. +  

    + +
    +

    Permission is granted to copy, distribute and/or modify +this document under the terms of the GNU Free Documentation License, Version +1.1 or any later version published by the Free Software Foundation; with +no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
    -  

    -
    -
    +  

    +
    +
    +
    diff --git a/STABLE/documentation/dhcp.htm b/STABLE/documentation/dhcp.htm index 14fe573ab..14816e07f 100644 --- a/STABLE/documentation/dhcp.htm +++ b/STABLE/documentation/dhcp.htm @@ -1,82 +1,85 @@ - + - + - + - + DHCP - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    DHCP

    -
    - +

    If you want to Run a DHCP Server on your firewall

    - +
      -
    • -

      Specify the "dhcp" option on each interface to be - served by your server in the /etc/shorewall/interfaces - file. This will generate rules that will allow DHCP to and from your -firewall system.

      -
      • -
    • -

      When starting "dhcpd", you need to list those interfaces -on the run line. On a RedHat system, this is done by modifying /etc/sysconfig/dhcpd. +

    • +

      Specify the "dhcp" option on each interface to be served +by your server in the /etc/shorewall/interfaces + file. This will generate rules that will allow DHCP to and from your firewall +system.

      +
      • +
    • +

      When starting "dhcpd", you need to list those interfaces +on the run line. On a RedHat system, this is done by modifying /etc/sysconfig/dhcpd.

      -
      • + +
    - +

    If a Firewall Interface gets its IP Address via DHCP

    - +
      -
    • -

      Specify the "dhcp" option for this interface in the - /etc/shorewall/interfaces - file. This will generate rules that will allow DHCP to and from your firewall +

    • +

      Specify the "dhcp" option for this interface in the + /etc/shorewall/interfaces + file. This will generate rules that will allow DHCP to and from your firewall system.

      -
      • -
    • -

      If you know that the dynamic address is always going -to be in the same subnet, you can specify the subnet address in the interface's - entry in the /etc/shorewall/interfaces +

      • +
    • +

      If you know that the dynamic address is always going to +be in the same subnet, you can specify the subnet address in the interface's + entry in the /etc/shorewall/interfaces file.

      -
      • -
    • -

      If you don't know the subnet address in advance, you -should specify "detect" for the interface's subnet address in the /etc/shorewall/interfaces file +

      • +
    • +

      If you don't know the subnet address in advance, you should + specify "detect" for the interface's subnet address in the /etc/shorewall/interfaces file and start Shorewall after the interface has started.

      -
      • -
    • -

      In the event that the subnet address might change while - Shorewall is started, you need to arrange for a "shorewall refresh" -command to be executed when a new dynamic IP address gets assigned to +

      • +
    • +

      In the event that the subnet address might change while + Shorewall is started, you need to arrange for a "shorewall refresh" +command to be executed when a new dynamic IP address gets assigned to the interface. Check your DHCP client's documentation.

      -
      • + +
    - +

    Last updated 11/03/2002 - Tom Eastep

    - -

    Copyright + +

    Copyright © 2001, 2002 Thomas M. Eastep.

    -
    +
    +
    diff --git a/STABLE/documentation/download.htm b/STABLE/documentation/download.htm index 9c3fcd3e6..617297ab7 100644 --- a/STABLE/documentation/download.htm +++ b/STABLE/documentation/download.htm @@ -1,191 +1,231 @@ - + - + - + - + Download - + - - - + + - - - + + + +
    - + id="AutoNumber1" bgcolor="#3366ff" height="90"> +
    +

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

    - +

    +

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

    - +     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 printed the appropriate QuickStart Guide, download one of the modules:

    - + - +

    The documentation in HTML format is included in the .tgz and .rpm files - and there is an documentation .deb that also contains the documentation.  The - .rpm will install the documentation in your default document directory -which can be obtained using the following command:
    -

    - -
    + and there is an documentation .deb that also contains the documentation.  The + .rpm will install the documentation in your default document directory + which can be obtained using the following command:
    +

    + +

    rpm --eval '%{defaultdocdir}'

    -
    - +
    +

    Please check the errata - to see if there are updates that apply to the version - that you have downloaded.

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

    - + 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 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.net +
    Hamburg, GermanyShorewall.netBrowseBrowse
    FranceShorewall.net +
    FranceShorewall.netBrowse Browse
    Taiwan
    -     		Greshko.com
    -     		+
    Taiwan
    +     		Greshko.com
    +     		Browse
    -     		Browse
    +
    Argentina
    +     		Shorewall.net
    +     		Browse
    +     		N/A
    +
    Brazil
    +     		securityopensource.org.br
    +     		Browse
    +     		N/A
    Washington State, USAShorewall.netWashington 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 3/24/2003 - contains the latest snapshots of the +each Shorewall component. There's no guarantee that what you +find there will work at all.
    +

    +
    + +

    Shapshots:
    +

    + +
    +

    Periodic snapshots from CVS may be found at http://shorewall.net/pub/shorewall/Snapshots + (FTP). + These snapshots have undergone initial testing and will have been installed + and run at shorewall.net.
    +

    +
    + +

    Last Updated 7/15/2003 - Tom Eastep

    - +

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

    +

    +
    +
    +
    +



    diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index d83aaea9e..b9f583a18 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -1,352 +1,355 @@ - + Shorewall 1.4 Errata + - + - + - + - + - - - + + - - - + + + +
    - + bgcolor="#3366ff" height="90"> +
    +

    Shorewall Errata/Upgrade Issues

    -
    - +

    IMPORTANT

    - +
      -
    1. - -

      If you use a Windows system to download - a corrected script, be sure to run the script through - + +

      If you use a Windows system to download + a corrected script, be sure to run the script through + dos2unix after you have moved + style="text-decoration: none;"> dos2unix after you have moved it to your Linux system.

      -
      2. -
    2. - -

      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 +

      3. +
    3. + +

      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.

      -
      4. -
    4. - -

      When the instructions say to install a corrected - firewall script in /usr/share/shorewall/firewall, you +

      5. +
    5. + +

      When the instructions say to install a corrected + firewall script in /usr/share/shorewall/firewall, you may rename the existing file before copying in the new file.

      -
      6. -
    6. - -

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

      -
      7. - + +
    7. + +

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

      +
      8. +
    - + - -
    + +

    Problems in Version 1.4

    - +

    - +

    1.4.4b

    - + - +

    1.4.4-1.4.4a

    - + - +

    1.4.4
    -

    - + +
      -
    • If you have zone names that are 5 characters long, you may experience - problems starting Shorewall because the --log-prefix in a logging rule -is too long. Upgrade to Version 1.4.4a to fix this problem..
      • - +
    • If you have zone names that are 5 characters long, you may experience + problems starting Shorewall because the --log-prefix in a logging rule is + too long. Upgrade to Version 1.4.4a to fix this problem..
      • +
    - +

    1.4.3

    - + - +

    1.4.2

    - -
      -
    • When an 'add' or 'delete' command is executed, a temporary directory - created in /tmp is not being removed. This problem may be corrected by -installing this firewall script in /usr/share/shorewall/firewall as -described above.
      -
      • - -
    - -

    1.4.1a, 1.4.1 and 1.4.0

      -
    • Some TCP requests are rejected in the 'common' chain with an - ICMP port-unreachable response rather than the more appropriate TCP RST - response. This problem is corrected in this updated common.def file which may be installed in - /etc/shorewall/common.def.
      +
    • When an 'add' or 'delete' command is executed, a temporary +directory created in /tmp is not being removed. This problem may be corrected +by installing this firewall script in /usr/share/shorewall/firewall +as described above.
    -

    1.4.1

    +

    1.4.1a, 1.4.1 and 1.4.0

      -
    • When a "shorewall check" command is executed, each "rule" -produces the harmless additional message:
      -
      -      /usr/share/shorewall/firewall: line 2174: [: =: unary operator - expected
      -
      - You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall - as described above.
      +
    • Some TCP requests are rejected in the 'common' chain with +an ICMP port-unreachable response rather than the more appropriate TCP +RST response. This problem is corrected in this updated common.def file which may be installed in + /etc/shorewall/common.def.
    -

    1.4.0

    +

    1.4.1

      -
    • When running under certain shells Shorewall will attempt -to create ECN rules even when /etc/shorewall/ecn is empty. You may either - just remove /etc/shorewall/ecn or you can install this - correct script in /usr/share/shorewall/firewall as described above.
      +
    • When a "shorewall check" command is executed, each "rule" +produces the harmless additional message:
      +
      +      /usr/share/shorewall/firewall: line 2174: [: =: unary operator + expected
      +
      + You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall + as described above.
    -
    -

    Upgrade Issues

    - -

    The upgrade issues have moved to a separate page.

    - -
    -

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

    - -

    I have built a - corrected 1.2.3 rpm which you can download here  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.

    - -

    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.

    - -

    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.

    - -

    To install one of the above patches:

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

    - -
    - 
    # 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").

    -
    - -

    Problems installing/upgrading - 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:

    +

    1.4.0

      -
    • set MULTIPORT=No - in /etc/shorewall/shorewall.conf; -or
      • -
    • if you - are running Shorewall 1.3.6 you may - install - this firewall script in /var/lib/shorewall/firewall - as described above.
      • - +
    • When running under certain shells Shorewall will attempt +to create ECN rules even when /etc/shorewall/ecn is empty. You may either + just remove /etc/shorewall/ecn or you can install this + correct script in /usr/share/shorewall/firewall as described above.
      +
      • +
    - + +
    +

    Upgrade Issues

    + +

    The upgrade issues have moved to a separate page.

    + +
    +

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

    + +

    I have built a + corrected 1.2.3 rpm which you can download here  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.

    + +

    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.

    + +

    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.

    + +

    To install one of the above patches:

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

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

    +
    + +

    Problems installing/upgrading + 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:

    + +
      +
    • set +MULTIPORT=No in /etc/shorewall/shorewall.conf; +or
      • +
    • if you + are running Shorewall 1.3.6 you may + install + this firewall script in /var/lib/shorewall/firewall + as described above.
      • + +
    +

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

    Problems with RH Kernels after 2.4.20-9 and REJECT -(also applies to 2.4.21-RC1)

    - Beginning with errata kernel 2.4.20-13.9, "REJECT --reject-with tcp-reset" -is broken. The symptom most commonly seen is that REJECT rules act just like -DROP rules when dealing with TCP. A kernel patch and precompiled modules to -fix this problem are available at + +

    Problems with RH Kernels after 2.4.20-9 and +REJECT (also applies to 2.4.21-RC1)

    + Beginning with errata kernel 2.4.20-13.9, "REJECT --reject-with tcp-reset" + is broken. The symptom most commonly seen is that REJECT rules act just +like DROP rules when dealing with TCP. A kernel patch and precompiled modules +to fix this problem are available at ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel.
    - -
    -

    Last updated 6/13/2003 - Tom Eastep -

    - + +
    +

    Last updated 6/13/2003 - Tom +Eastep

    +

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

    +

    +
    diff --git a/STABLE/documentation/errata_1.htm b/STABLE/documentation/errata_1.htm index cdd1e06c3..351893bed 100644 --- a/STABLE/documentation/errata_1.htm +++ b/STABLE/documentation/errata_1.htm @@ -1,215 +1,196 @@ + - - - - - -Shorewall Errata for Version 1 + + + + + + + + + Shorewall Errata for Version 1 - - - - - - - + + +
    -

    Shorewall Errata for Version 1.1

    -
    + + + + + +
    +

    Shorewall Errata for Version +1.1

    +
    - -

    To those of you who downloaded the 1.1.13 updated firewall script prior -to Sept 20, 2001:

    - -
    - -

    Prior -to 20:00 20 Sept 2001 GMT, the link under 1.1.13 pointed to a broken version -of the firewall script. This has now been corrected. I apologize for any confusion -this may have caused.

    + +

    To those of you who downloaded +the 1.1.13 updated firewall script prior to Sept 20, 2001:

    + +
    +

    Prior to 20:00 20 Sept 2001 GMT, the link under 1.1.13 +pointed to a broken version of the firewall script. This has now been corrected. +I apologize for any confusion this may have caused.

    +
    + +

    Version 1.1.18

    + +
    +

    In the original .lrp, /etc/init.d/shorewall was not + secured for execute access. I have replaced the incorrect .lrp + (shorwall-1.1.18.lrp) with a corrected one (shorwall-1.1.18a.lrp).

    - -

    Version 1.1.18

    - -
    - -

    In the original .lrp, /etc/init.d/shorewall was not - secured for execute access. I have replaced the incorrect .lrp - (shorwall-1.1.18.lrp) with a corrected one (shorwall-1.1.18a.lrp).

    - -
    - -

    - Version 1.1.17

    - -
    - -

    In - shorewall.conf, ADD_IP_ALIASES was incorrectly spelled - IP_ADD_ALIASAES. There is a corrected version of the file here.

    - -

    This - problem is also corrected in version 1.1.18.

    -
    - -

    - Version 1.1.16

    - -
    -

    - The ADD_IP_ALIASES variable added in 1.1.16 was incorrectly spelled IP_ADD_ALIASES -in the firewall script. To correct this problem, install the - corrected firewall script - in the location pointed to by the symbolic link /etc/shorewall/firewall.

    - -

    - This problem is also corrected in version 1.1.17.

    -
    - -

    - Version 1.1.14-1.1.15

    - -
    -

    - There are no corrections for these versions.

    -
    - -

    - Version 1.1.13

    - -
    -

    - The firewall fails to start if a rule with the following format is given:

    - -

    - <disposition>    z1:www.xxx.yyy.zzz    z2    proto    p1,p2,p3

    - -

    - To correct this problem, install - this corrected firewall script - in the location pointed to by the symbolic link /etc/shorewall/firewall. 

    -
    - -

    - Version 1.1.12

    - -
    -

    - The LRP version of Shorewall 1.1.12 has the incorrect /etc/shorewall/functions -file. This incorrect file results in many error messages of the form:

    - -
    -

    - separate_list: not found

    -
    - -

    - The correct file may be obtained here - . This problem is also corrected in version 1.1.13.

    -
    - -

    - Version 1.1.11

    - -
    -

    - There are no known problems with this version.

    -
    - -

    - Version 1.1.10

    - -
    -

    - If the following conditions were met:
    -

    - -
      - -
    1. -

      - A LAN segment attached to the firewall was served by a DHCP server -running on the firewall.

      -
      2. - -
    2. -

      - There were entries in /etc/shorewall/hosts that referred to the -interface to that LAN segment.

      -
      3. - -
    - -

    - then up until now it has been necessary to include entries for 0.0.0.0 -and 255.255.255.255 for that interface in /etc/shorewall/hosts. - This version of the firewall script - makes those additions unnecessary provided that you simply include -"dhcp" in the options for the interface in /etc/shorewall/interfaces. -Install the script into the location pointed to by the symbolic link -/etc/shorewall/firewall.

    - -

    - This problem has also been corrected in version 1.1.11.

    -
    - -

    - Version 1.1.9

    - + +

    Version 1.1.17

    + +
    +

    In shorewall.conf, ADD_IP_ALIASES was incorrectly +spelled IP_ADD_ALIASAES. There is a corrected version of the +file here.

    + +

    This problem is also corrected in version 1.1.18.

    +
    + +

    Version 1.1.16

    + +
    +

    The ADD_IP_ALIASES variable added in 1.1.16 was incorrectly + spelled IP_ADD_ALIASES in the firewall script. To correct this problem, + install the corrected + firewall script in the location pointed to by the symbolic link + /etc/shorewall/firewall.

    + +

    This problem is also corrected in version 1.1.17.

    +
    + +

    Version 1.1.14-1.1.15

    + +
    +

    There are no corrections for these versions.

    +
    + +

    Version 1.1.13

    + +
    +

    The firewall fails to start if a rule with the following + format is given:

    + +

    <disposition>    z1:www.xxx.yyy.zzz    z2    + proto    p1,p2,p3

    + +

    To correct this problem, install this + corrected firewall script in the location pointed to by the symbolic +link /etc/shorewall/firewall. 

    +
    + +

    Version 1.1.12

    + +
    +

    The LRP version of Shorewall 1.1.12 has the incorrect + /etc/shorewall/functions file. This incorrect file results in many error + messages of the form:

    + +
    +

    separate_list: not found

    +
    + +

    The + correct file may be obtained here . This problem is also corrected +in version 1.1.13.

    +
    + +

    Version 1.1.11

    + +
    +

    There are no known problems with this version.

    +
    + +

    Version 1.1.10

    + +
    +

    If the following conditions were met:
    +

    + +
      +
    1. +

      A LAN segment attached to the firewall was served +by a DHCP server running on the firewall.

      +
      2. +
    2. +

      There were entries in /etc/shorewall/hosts that referred + to the interface to that LAN segment.

      +
      3. + +
    + +

    then up until now it has been necessary to include entries + for 0.0.0.0 and 255.255.255.255 for that interface in /etc/shorewall/hosts. + + This version of the firewall script makes those additions unnecessary + provided that you simply include "dhcp" in the options for the interface +in /etc/shorewall/interfaces. Install the script into the location pointed +to by the symbolic link /etc/shorewall/firewall.

    + +

    This problem has also been corrected in version 1.1.11.

    +
    + +

    Version 1.1.9

    + - - -

    Version 1.1.8

    - + +

    Version 1.1.8

    +
      -
    • Under some circumstances, the "dhcp" option on an interface triggers -a bug in the firewall script that results in a "chain already exists" -error. - This version of the firewall script - corrects this problem. Install it into the location pointed to by -the symbolic link /etc/shorewall/firewall.
      -
      - This problem is also corrected in version 1.1.9.
      - - -
      • +
    • Under some circumstances, the "dhcp" option on an interface triggers +a bug in the firewall script that results in a "chain already exists" +error. This + version of the firewall script corrects this problem. Install +it into the location pointed to by the symbolic link /etc/shorewall/firewall.
      +
      + This problem is also corrected in version 1.1.9.
      +
      • +
    - - -

    Version 1.1.7

    - + +

    Version 1.1.7

    +
      -
    • If the /etc/shorewall/rules template from version 1.1.7 is used, a warning -message appears during firewall startup:
      -
      -     Warning: Invalid Target - rule "@ icmp-unreachable packet." +
    • If the /etc/shorewall/rules template from version 1.1.7 is used, +a warning message appears during firewall startup:
      +
      +     Warning: Invalid Target - rule "@ icmp-unreachable packet." ignored
      -
      - This warning may be eliminated by replacing the "@" in column 1 of +
      + This warning may be eliminated by replacing the "@" in column 1 of line 17 with "#"
      • +
    - -
    -

    - This problem is also corrected in version 1.1.8

    -
    - -

    - Last updated 12/21/2001 - - Tom Eastep -

    - -

    -Copyright © 2001, 2002 Thomas M. Eastep.

    - + +
    +

    This problem is also corrected in version 1.1.8

    +
    + +

    Last updated 12/21/2001 - Tom Eastep

    + +

    Copyright +© 2001, 2002 Thomas M. Eastep.

    +
    - diff --git a/STABLE/documentation/errata_2.htm b/STABLE/documentation/errata_2.htm index d1e23d8c6..a6f430238 100644 --- a/STABLE/documentation/errata_2.htm +++ b/STABLE/documentation/errata_2.htm @@ -1,439 +1,425 @@ - - + + Shorewall 1.2 Errata - + - + - - - - - - - - -
    -

    Shorewall 1.2 Errata

    -
    - -

    - - - IMPORTANT

    - -

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

    - -

    - - When the instructions say to install a corrected firewall script in - /etc/shorewall/firewall, use the 'cp' (or 'scp') utility to overwrite the - existing file. DO NOT REMOVE OR RENAME THE OLD /etc/shorewall/firewall - before you do that. /etc/shorewall/firewall is a symbolic link that points - to the 'shorewall' file used by your system initialization scripts to - start Shorewall during boot and it is that file that must be overwritten - with the corrected script.

    - - -
    - -

    Problems in Version 1.2

    - -

    Version 1.2.13

    - -
      -
    • - -

      Some users have reported problems installing the RPM - on SuSE 7.3 where rpm reports a conflict with kernel <= 2.2 even - though a 2.4 kernel RPM is installed. To get around this problem, use - the --nodeps option to rpm (e.g., "rpm -ivh --nodeps - shorewall-1.2-13.noarch.rpm").
      -
      - The problem stems from the fact that SuSE does not - include a package named "kernel" but rather has a number of packages - that provide the virtual package "kernel". Since virtual packages have - no version associated with them, a conflict results. Since the - workaround is simple, I don't intend to change the Shorewall package.

      - -
      • -
    • - -

      Shorewall accepts invalid rules of the form:
      -
      - ACCEPT <src> <dest>:<ip addr> all <port number> - - <original ip address>
      -
      -       The <port number> is ignored with the result that all - connection requests from the <src> zone whose original destination IP - address matches the last column are forwarded to the <dest> zone, IP - address <ip addr>.  - - This corrected firewall script correctly generates an error when + + + + + + + + + + +
      +

      Shorewall 1.2 Errata

      +
      + +

      + IMPORTANT

      + +

      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.

      + +

      When the instructions say to install a corrected +firewall script in /etc/shorewall/firewall, use the 'cp' (or 'scp') +utility to overwrite the existing file. DO NOT REMOVE OR RENAME THE +OLD /etc/shorewall/firewall before you do that. /etc/shorewall/firewall +is a symbolic link that points to the 'shorewall' file used by your +system initialization scripts to start Shorewall during boot and it +is that file that must be overwritten with the corrected script.

      + + + +
      +

      Problems in Version 1.2

      + +

      Version 1.2.13

      + +
        +
      • +

        Some users have reported problems installing the RPM + on SuSE 7.3 where rpm reports a conflict with kernel <= 2.2 even + though a 2.4 kernel RPM is installed. To get around this problem, +use the --nodeps option to rpm (e.g., "rpm -ivh --nodeps + shorewall-1.2-13.noarch.rpm").
        +
        + The problem stems from the fact that SuSE does not include +a package named "kernel" but rather has a number of packages that +provide the virtual package "kernel". Since virtual packages have + no version associated with them, a conflict results. Since the + workaround is simple, I don't intend to change the Shorewall package.

        +
        • +
      • +

        Shorewall accepts invalid rules of the form:
        +
        + ACCEPT <src> <dest>:<ip addr> +all <port number> - <original ip address>
        +
        +         The <port number> is ignored with the result that + all connection requests from the <src> zone whose +original destination IP address matches the last column are forwarded +to the <dest> zone, IP address <ip addr>.  + + This corrected firewall script correctly generates an error when such a rule is encountered.

        - -
        • -
      - -

      Version 1.2.11

      - -
        -
      • - -

        The 'try' command is broken.

        • -
      • - -

        The usage text printed by the shorewall utility - doesn't show the optional timeout for the 'try' command.

        • -
      - -

      Both problems are corrected by - - this new version of /sbin/shorewall.

      - -

      Sample Configurations:

      - -
        -
      • - -

        There have been several problems with SSH, DNS and - ping in the two- and three-interface examples. Before reporting - problems with these services, please verify that you have the latest - version of the appropriate sample 'rules' file.

        • -
      - -

      All Versions through 1.2.10

      - - -
      -
      - - - - - - - - - - - - - - - - -
      ZONEHOST(S)OPTIONS
      loceth2:192.168.1.0/24routestopped
      locppp+:192.168.1.0/24 
      -
      -
      - -

      All Versions through 1.2.8

      - -
        -
      • - -

        The shorewall.conf file and the documentation - incorrectly refer to a parameter in /etc/shorewall/shorewall.conf - called LOCKFILE; the correct name for the parameter is SUBSYSLOCK (see - the corrected online documentation). Users of the rpm should - change the name (and possibly the value) of this parameter so that - Shorewall interacts properly with the SysV init scripts. The - documentation on this web site has been corrected and - +

        • + +
      + +

      Version 1.2.11

      + +
        +
      • +

        The 'try' command is broken.

        +
        • +
      • +

        The usage text printed by the shorewall utility + doesn't show the optional timeout for the 'try' command.

        +
        • +
      + +

      Both problems are corrected by + this new version of /sbin/shorewall.

      + +

      Sample Configurations:

      + +
        +
      • +

        There have been several problems with SSH, DNS and + ping in the two- and three-interface examples. Before reporting + problems with these services, please verify that you have the latest + version of the appropriate sample 'rules' file.

        +
        • +
      + +

      All Versions through 1.2.10

      + + + +
      +
      + + + + + + + + + + + + + + + + + + + +
      ZONEHOST(S)OPTIONS
      loceth2:192.168.1.0/24routestopped
      locppp+:192.168.1.0/24 
      +
      +
      + +

      All Versions through 1.2.8

      + +
        +
      • +

        The shorewall.conf file and the documentation + incorrectly refer to a parameter in /etc/shorewall/shorewall.conf + called LOCKFILE; the correct name for the parameter is SUBSYSLOCK (see the corrected online documentation). +Users of the rpm should change the name (and possibly the value) +of this parameter so that Shorewall interacts properly with the +SysV init scripts. The documentation on this web site has been +corrected and here's a corrected version of shorewall.conf.

        - -
        • -
      • - -

        The documentation indicates that a comma-separated - list of IP/subnet addresses may appear in an entry in the hosts file. - This is not the case; if you want to specify multiple addresses for a - zone, you need to have a separate entry for each address.

        - -
        • -
      - -

      Version 1.2.7

      - -

      Version 1.2.7 is quite broken -- please install 1.2.8

      - -

      If you have installed and started version 1.2.7 then before trying - to restart under 1.2.8:

      -
        -
      1. Look at your /etc/shorewall/shorewall.conf file and note the directory - named in the STATEDIR variable. If that variable is empty, assume - /var/state/shorewall.
        2. -
      2. Remove the file 'lock' in the directory determined in step 1.
        3. -
      -

      You may now restart using 1.2.8.

      - -

      Version 1.2.6

      - -
        -
      • - -

        GRE and IPIP tunnels are broken.

        • -
      • - -

        The following rule results in a start error:
        -
        -    ACCEPT    z1    z2    - icmp

        • -
      - -

      To correct the above problems, install - this - corrected firewall script in  /etc/shorewall/firewall..

      Version 1.2.5

      - -
        -
      • - -

        The new ADDRESS column in /etc/shorewall/masq cannot - contain a $-variable name.

        • -
      • - -

        Errors result if $FW appears in the - /etc/shorewall/policy file.

        • -
      • - -

        Using Blacklisting without setting BLACKLIST_LOGLEVEL - results in an error at start time.

        • -
      - -

      To correct the above problems, install - this - corrected firewall script in /etc/shorewall/firewall.

       

      - -

      Version 1.2.4

      - -
        -

      • This version will not install "out of the box" without - modification. Before attempting to start the - firewall, please change the STATEDIR in /etc/shorewall/shorewall.conf to - refer to /var/lib/shorewall. This only applies to fresh installations -- if - you are upgrading from a previous version of Shorewall, version 1.2.4 will - work without modification.

        • -
      - -

      Version 1.2.3

      - - -
      - -

      Alternatively, edit /etc/shorewall/firewall and change line 1564 from:

      - -
      - 
                run_iptables -A blacklst -d $addr -j LOG $LOGPARAMS --log-prefix \
      -
      - -

      to

      - -
      - 
                run_iptables -A blacklst -s $addr -j LOG $LOGPARAMS --log-prefix \
      - -

      Version 1.2.2

      - -
        -
      • The "shorewall status" command hangs after - it displays the chain information. Here's - a corrected /sbin/shorewall. if  you want to simply modify your copy of - /sbin/shorewall, then at line 445 change this:
        • -
      - -
      - - 
             status)
-           clear
      - -
      -
      - -

      to this:

      - -
      -
      - - 
             status)
-           get_config
-           clear
      - -
      -
        -
      • The "shorewall monitor" command - doesn't show the icmpdef chain - this - corrected /sbin/shorewall fixes that problem as well as the status - problem described above.
        • -
      -
        -
      • In all 1.2.x versions, the 'CLIENT PORT(S)' - column in /etc/shorewall/tcrules is ignored. This is corrected in this - updated firewall script.  Place the script in /etc/shorewall/firewall. Thanks to Shingo Takeda for - spotting this bug.
        • -
      - -

      Version 1.2.1

      - -
        -
      • The new logunclean interface option is not - described in the help text in /etc/shorewall/interfaces. An updated - interfaces file is available.
        • -
      • When REJECT is specified in a TCP rule, Shorewall - correctly replies with a TCP RST packet. Previous versions of the - firewall script are broken in the case of a REJECT policy, however; in - REJECT policy chains, all requests are currently replied to with an - ICMP port-unreachable packet. This - corrected firewall script replies to TCP requests with TCP RST in - REJECT policy chains. Place the script in /etc/shorewall/firewall.
        • -
      - -

      Version 1.2.0

      - -
      - -

      Note: If you are upgrading from one of the Beta - RPMs to 1.2.0, you must use the "--oldpackage" option to rpm - (e.g., rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm).

      - -

      The tunnel script released in version 1.2.0 contained - errors -- a corrected - script is available.

      - -
      - -
      - -

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

      - -

      I have built a - corrected 1.2.3 rpm which you can download here  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.

      - -

      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.

      - -

      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.

      - -

      To install one of the above patches:

      -
        -
      • cd iptables-1.2.3/extensions
        • -
      • patch -p0 < the-patch-file
        • -
      - -
      - -

      Problems with kernel 2.4.18 - and RedHat iptables

      -
      -

      Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18 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 documentation indicates that a comma-separated + list of IP/subnet addresses may appear in an entry in the hosts file. + This is not the case; if you want to specify multiple addresses +for a zone, you need to have a separate entry for each address.

      +
      • + +
    + +

    Version 1.2.7

    + +

    Version 1.2.7 is quite broken -- please install 1.2.8

    + +

    If you have installed and started version 1.2.7 then before trying + to restart under 1.2.8:

    + +
      +
    1. Look at your /etc/shorewall/shorewall.conf file and note the directory + named in the STATEDIR variable. If that variable is empty, assume /var/state/shorewall.
      2. +
    2. Remove the file 'lock' in the directory determined in step 1.
      3. + +
    + +

    You may now restart using 1.2.8.

    + +

    Version 1.2.6

    + +
      +
    • +

      GRE and IPIP tunnels are broken.

      +
      • +
    • +

      The following rule results in a start error:
      +
      +     ACCEPT    z1    z2    icmp

      +
      • +
    + +

    To correct the above problems, install this + corrected firewall script in  /etc/shorewall/firewall..

    +

    Version 1.2.5

    + +
      +
    • +

      The new ADDRESS column in /etc/shorewall/masq cannot + contain a $-variable name.

      +
      • +
    • +

      Errors result if $FW appears in the /etc/shorewall/policy +file.

      +
      • +
    • +

      Using Blacklisting without setting BLACKLIST_LOGLEVEL + results in an error at start time.

      +
      • +
    + +

    To correct the above problems, install this + corrected firewall script in /etc/shorewall/firewall.

    +

     

    + + +

    Version 1.2.4

    + +
      +
    • +

      This version will not install "out of the box" without + modification. Before attempting to start the firewall, please change +the STATEDIR in /etc/shorewall/shorewall.conf to refer to /var/lib/shorewall. +This only applies to fresh installations -- if you are upgrading from +a previous version of Shorewall, version 1.2.4 will work without modification. +

      +
      • +
    + +

    Version 1.2.3

    + + + +
    +

    Alternatively, edit /etc/shorewall/firewall and change line 1564 from:

    -

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

    -
    - -

    - Last updated 5/24/2002 - - Tom Eastep -

    - -

    Copyright + +

              run_iptables -A blacklst -d $addr -j LOG $LOGPARAMS --log-prefix \
    + +
    +

    to

    +
    + +
              run_iptables -A blacklst -s $addr -j LOG $LOGPARAMS --log-prefix \
    + +

    Version 1.2.2

    + +     + +
    +
           status)
               clear
    +
    + +
    +

    to this:

    +
    + +
    +
           status)
               get_config
               clear
    +
    + +
      +
    • The "shorewall monitor" command doesn't show the icmpdef chain +- this corrected /sbin/shorewall +fixes that problem as well as the status problem described above.
      • + +
    + +
      +
    • In all 1.2.x versions, the 'CLIENT PORT(S)' column in /etc/shorewall/tcrules +is ignored. This is corrected in this updated firewall script.  +Place the script in /etc/shorewall/firewall. Thanks to Shingo Takeda for + spotting this bug.
      • + +
    + +

    Version 1.2.1

    + +
      +
    • The new logunclean interface option is not described +in the help text in /etc/shorewall/interfaces. An updated + interfaces file is available.
      • +
    • When REJECT is specified in a TCP rule, Shorewall correctly +replies with a TCP RST packet. Previous versions of the firewall +script are broken in the case of a REJECT policy, however; in REJECT +policy chains, all requests are currently replied to with an ICMP +port-unreachable packet. This + corrected firewall script replies to TCP requests with TCP +RST in REJECT policy chains. Place the script in /etc/shorewall/firewall.
      • + +
    + +

    Version 1.2.0

    + +
    +

    Note: If you are upgrading from one of the Beta + RPMs to 1.2.0, you must use the "--oldpackage" option to rpm + (e.g., rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm).

    + +

    The tunnel script released in version 1.2.0 contained + errors -- a corrected + script is available.

    +
    + +
    +

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

    + +

    I have built a + corrected 1.2.3 rpm which you can download here  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.

    + +

    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.

    + +

    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.

    + +

    To install one of the above patches:

    + +
      +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • + +
    +
    + +

    Problems with kernel 2.4.18 + and RedHat iptables

    + +
    +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18 +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").

    +
    + +

    Last updated +5/24/2002 - Tom Eastep

    + +

    Copyright © 2001, 2002 Thomas M. Eastep.

    - +
    - \ No newline at end of file + diff --git a/STABLE/documentation/errata_3.html b/STABLE/documentation/errata_3.html index 59cc0fc9a..fe34058ff 100644 --- a/STABLE/documentation/errata_3.html +++ b/STABLE/documentation/errata_3.html @@ -1,703 +1,644 @@ - - + Shorewall 1.3 Errata - - - + - - + - - + - + - - - + + - - - - + + + +
    - - + bgcolor="#3366ff" height="90"> +

    Shorewall Errata/Upgrade Issues

    -
    - +

    IMPORTANT

    - +
      -
    1. - - -

      If you use a Windows system to download - a corrected script, be sure to run the script through - dos2unix after you have moved +

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

      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 +

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

      If you are running a Shorewall version earlier - than 1.3.11, when the instructions say to install a corrected -firewall script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall - or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to -overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD -/etc/shorewall/firewall or /var/lib/shorewall/firewall before -you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall - are symbolic links that point to the 'shorewall' file used by -your system initialization scripts to start Shorewall during -boot. It is that file that must be overwritten with the corrected -script. Beginning with Shorewall 1.3.11, you may rename the existing file +

      6. +
    6. +

      If you are running a Shorewall version earlier + than 1.3.11, when the instructions say to install a corrected firewall + script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall + or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to +overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD +/etc/shorewall/firewall or /var/lib/shorewall/firewall before +you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall + are symbolic links that point to the 'shorewall' file used by your + system initialization scripts to start Shorewall during boot. +It is that file that must be overwritten with the corrected +script. Beginning with Shorewall 1.3.11, you may rename the existing file before copying in the new file.

      -
      7. -
    7. - -

      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 +

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

      + +
    - + - -
    + +

    Problems in Version 1.3

    - - +

    Version 1.3.14

    - +
      -
    • There is an updated - rfc1918 file that reflects the resent allocation of 222.0.0.0/8 and +
    • There is an updated + rfc1918 file that reflects the resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
      • - +
    - +
      -
    • The documentation for the routestopped file claimed that a comma-separated - list could appear in the second column while the code only supported a single - host or network address.
      • -
    • Log messages produced by 'logunclean' and 'dropunclean' were not rate-limited.
      • -
    • 802.11b devices with names of the form wlan<n> don't +
    • The documentation for the routestopped file claimed that a comma-separated + list could appear in the second column while the code only supported a +single host or network address.
      • +
    • Log messages produced by 'logunclean' and 'dropunclean' were not +rate-limited.
      • +
    • 802.11b devices with names of the form wlan<n> don't support the 'maclist' interface option.
      • -
    • Log messages generated by RFC 1918 filtering are not rate limited.
      • -
    • The firewall fails to start in the case where you have "eth0 eth1" +
    • Log messages generated by RFC 1918 filtering are not rate limited.
      • +
    • The firewall fails to start in the case where you have "eth0 eth1" in /etc/shorewall/masq and the default route is through eth1.
      -
      • - + +
    - These problems have been corrected in this - firewall script which may be installed in /usr/lib/shorewall as described + These problems have been corrected in this + firewall script which may be installed in /usr/lib/shorewall as described above.
    - +

    Version 1.3.13

    - +
      -
    • The 'shorewall add' command produces an error message referring +
    • The 'shorewall add' command produces an error message referring to 'find_interfaces_by_maclist'.
      • -
    • The 'shorewall delete' command can leave behind undeleted rules.
      • -
    • The 'shorewall add' command can fail with "iptables: Index of insertion - too big".
      -
      • - -
    - All three problems are corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
    - -
      -
    • VLAN interface names of the form "ethn.m" (e.g., -eth0.1) are not supported in this version or in 1.3.12. If you need such -support, post on the users list and I can provide you with a patched version.
      +
    • The 'shorewall delete' command can leave behind undeleted rules.
      • +
    • The 'shorewall add' command can fail with "iptables: Index of +insertion too big".
      • - +
    - -

    Version 1.3.12

    - + All three problems are corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
    +
      -
    • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect - is the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem - is corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
      • -
    • VLAN interface names of the form "ethn.m" (e.g., -eth0.1) are not supported in this version or in 1.3.13. If you need such +
    • VLAN interface names of the form "ethn.m" (e.g., +eth0.1) are not supported in this version or in 1.3.12. If you need such support, post on the users list and I can provide you with a patched version.
      • - +
    - + +

    Version 1.3.12

    + +
      +
    • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect + is the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem + is corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
      • +
    • VLAN interface names of the form "ethn.m" (e.g., +eth0.1) are not supported in this version or in 1.3.13. If you need such +support, post on the users list and I can provide you with a patched version.
      +
      • + +
    +

    Version 1.3.12 LRP

    - +
      -
    • The .lrp was missing the /etc/shorewall/routestopped file --- a new lrp (shorwall-1.3.12a.lrp) has been released which corrects -this problem.
      -
      • - -
    - -

    Version 1.3.11a

    - -
      -
    • This - copy of /etc/shorewall/rfc1918 reflects the recent allocation of -82.0.0.0/8.
      +
    • The .lrp was missing the /etc/shorewall/routestopped file +-- a new lrp (shorwall-1.3.12a.lrp) has been released which corrects this + problem.
      • - +
    - + +

    Version 1.3.11a

    + + +

    Version 1.3.11

    - +
      -
    • When installing/upgrading using the .rpm, you may receive +
    • 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 +
      +      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 +
    • 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 +
      + 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.
      -
      • - +
      + 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, +
    • 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.
      -
      • - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.10/firewall">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 +
    • 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 + target="_top">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.
    -
    - -
    Alternatively, edit /usr/lob/shorewall/firewall and change the - single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' +
    + +
    Alternatively, edit /usr/lob/shorewall/firewall and change the + single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' to 'recalculate_interface'.
    -
    - + +
      -
    • The installer (install.sh) issues a misleading message - "Common functions installed in /var/lib/shorewall/functions" whereas - the file is installed in /usr/lib/shorewall/functions. The installer - also performs incorrectly when updating old configurations that had the +
    • The installer (install.sh) issues a misleading message + "Common functions installed in /var/lib/shorewall/functions" whereas + the file is installed in /usr/lib/shorewall/functions. The installer + also performs incorrectly when updating old configurations that had the file /etc/shorewall/functions. Here + href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.3.9/install.sh">Here is an updated version that corrects these problems.
      -
      • - + +
    - +

    Version 1.3.9

    - TUNNELS Broken in 1.3.9!!! There is an updated + TUNNELS Broken in 1.3.9!!! There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + target="_top">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 +
    + Version 1.3.8
      -
    • Use of shell variables in the LOG LEVEL or SYNPARMS +
    • 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 +
    • 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. + Installing + this corrected firewall script in /var/lib/shorewall/firewall + 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 + +

    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.

    - - +

    Version 1.3.7a

    - - -

    "shorewall refresh" is not creating the proper - rule for FORWARDPING=Yes. Consequently, after - "shorewall refresh", the firewall will not forward - icmp echo-request (ping) packets. Installing + +

    "shorewall refresh" is not creating the proper rule for FORWARDPING=Yes. +Consequently, after "shorewall refresh", the firewall will not +forward icmp echo-request (ping) packets. Installing - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this + href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall"> + this corrected firewall script in /var/lib/shorewall/firewall + 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 + +

    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:

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

    - - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall"> + This version of the 1.3.7a firewall script + 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 + +

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

    In other words, type "md5sum <whatever package you downloaded> 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 + +

    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.

    - +

    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 +

    • +

      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.

      -
      • -
    • - - -

      The logunclean and dropunclean options - cause errors during startup when Shorewall is run with iptables +

      • +
    • +

      The logunclean and dropunclean options + cause errors during startup when Shorewall is run with iptables 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.

    - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall"> + 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:

    - + +

    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:

    +

    net    eth0    detect    routefilter,dhcp,norfc1918

    - -

    If you downloaded two-interfaces-a.tgz then the above - line should already be in the file.

    - + +

    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.

    - + +

    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:

    - -
    + +

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

    + +
    +

    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 + href="http://www.shorewall.net/pub/shorewall/errata/1.3.5a/firewall">this + 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 + +

    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.

    - +

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

    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.

    - +

    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.

    - + +

    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.

    +

    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.

    - + +

    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 +
    • 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; +
    • "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 + href="http://www.shorewall.net/pub/shorewall/errata/1.3.2/firewall"> + this script which should be installed in /var/lib/shorewall as described above.

    - +
      -
    • - - -

      The IANA have just announced the allocation of subnet +

    • +

      The IANA have just announced the allocation of subnet 221.0.0.0/8. This - updated rfc1918 file reflects that allocation.

      -
      • - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.2/rfc1918"> + 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 +
    • 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 +
    • 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 +
    • 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 +
      + 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 + href="http://www.shorewall.net/pub/shorewall/errata/1.3.1/firewall"> + this firewall script which should be installed in /etc/shorewall/firewall as described above.

    - +

    Version 1.3.0

    - +
      -
    • Folks who downloaded 1.3.0 from the - links on the download page before 23:40 GMT, 29 May - 2002 may have downloaded 1.2.13 rather than 1.3.0. -The "shorewall version" command will tell you which version - that you have installed.
      • -
    • The documentation NAT.htm file uses - non-existent wallpaper and bullet graphic files. The - - corrected version is here.
      • - +
    • Folks who downloaded 1.3.0 from the + links on the download page before 23:40 GMT, 29 May + 2002 may have downloaded 1.2.13 rather than 1.3.0. +The "shorewall version" command will tell you which version + that you have installed.
      • +
    • The documentation NAT.htm file uses + non-existent wallpaper and bullet graphic files. The + + corrected version is here.
      • +
    - -
    + +

    Upgrade Issues

    - +

    The upgrade issues have moved to a separate page.

    - -
    -

    Problem with + +
    +

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

    - - + +
    +

    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. 

    +

    I have built a - corrected 1.2.3 rpm which you can download here  and I have + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm"> + corrected 1.2.3 rpm which you can download here  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.

    - - -

    Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can + href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm"> 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.

    + +

    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 + href="http://www.redhat.com/support/errata/RHSA-2001-144.html">http://www.redhat.com/support/errata/RHSA-2001-144.html. + I have installed this RPM on my firewall and it works fine.

    - - -

    If you would like to patch iptables 1.2.3 yourself, + +

    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 + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/loglevel.patch">patch + which corrects a problem with parsing of the --log-level specification while this patch + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/tos.patch">patch 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 +

    + +

    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:

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

    + +

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

    -
    - - -

    Problems installing/upgrading +

    + +

    Problems installing/upgrading 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.

    - - + +

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

    +
      -
    • set MULTIPORT=No +
    • set MULTIPORT=No in /etc/shorewall/shorewall.conf; or
      • -
    • if you are running - Shorewall 1.3.6 you may install +
    • if you are running + Shorewall 1.3.6 you may install - this firewall script in /var/lib/shorewall/firewall + href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall"> + this firewall script in /var/lib/shorewall/firewall as described above.
      • - +
    - +

    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:
    -
    - + + /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:
    - + 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 + 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 3/8/2003 - -Tom Eastep

    - + +

    Last updated 3/8/2003 - Tom Eastep +

    +

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

    +

    +



    diff --git a/STABLE/documentation/fallback.htm b/STABLE/documentation/fallback.htm index f9309f4ce..1141bd0b6 100644 --- a/STABLE/documentation/fallback.htm +++ b/STABLE/documentation/fallback.htm @@ -1,74 +1,77 @@ + - - -Shorewall Fallback and Uninstall - - + + + Shorewall Fallback and Uninstall + + + + - - - - - - - + + +
    - -

    Fallback and Uninstall

    - -
    + + + + + +
    +

    Fallback and Uninstall

    +
    - -

    Shorewall includes -a fallback script -and an uninstall script.

    - -

    Falling Back to the Previous Version of Shorewall + +

    Shorewall includes a fallback +script and an uninstall +script.

    + +

    Falling Back to the Previous Version of Shorewall using the Fallback Script

    - -

    If you install Shorewall and discover that -it doesn't work for you, you can fall back to your previously -installed version. To do that:

    - + +

    If you install Shorewall and discover that it doesn't work for you, you +can fall back to your previously installed version. To do that:

    +
      -
    • cd to the distribution directory for the version - of Seattle Firewall that you are - currently running (NOT the version - that you want to fall back to).
      • -
    • Type "./fallback.sh"
      • +
    • cd to the distribution directory for the version of Seattle +Firewall that you are currently running (NOT the version + that you want to fall back to).
      • +
    • Type "./fallback.sh"
      • +
    - -

    Warning: The fallback script -will replace /etc/shorewall/policy, /etc/shorewall/rules, /etc/shorewall/interfaces, -/etc/shorewall/nat, /etc/shorewall/proxyarp and /etc/shorewall/masq with the version of -these files from before the current version was installed. Any -changes to any of these files will be lost.

    - -

    Falling Back to the Previous Version of Shorewall using + +

    Warning: The fallback script will replace /etc/shorewall/policy, +/etc/shorewall/rules, /etc/shorewall/interfaces, /etc/shorewall/nat, /etc/shorewall/proxyarp +and /etc/shorewall/masq with the version of these files from before the current +version was installed. Any changes to any of these files will be lost.

    + +

    Falling Back to the Previous Version of Shorewall using rpm

    - -

    If your previous version of Shorewall was -installed using RPM, you may fall back to that version by typing -"rpm -Uvh --force <old rpm>" at a root shell -prompt (Example: "rpm -Uvh --force /downloads/shorewall-3.1=0noarch.rpm" would fall back to the 3.1-0 -version of Shorewall).

    - + +

    If your previous version of Shorewall was installed using RPM, you may +fall back to that version by typing "rpm -Uvh --force <old rpm>" at +a root shell prompt (Example: "rpm -Uvh --force /downloads/shorewall-3.1=0noarch.rpm" +would fall back to the 3.1-0 version of Shorewall).

    +

    Uninstalling Shorewall

    - -

    If you no longer wish to use Shorewall, you -may remove it by:

    - + +

    If you no longer wish to use Shorewall, you may remove it by:

    +
      -
    • cd to the distribution directory for the version - of Shorewall that you have installed.
      • -
    • type "./uninstall.sh"
      • +
    • cd to the distribution directory for the version of Shorewall +that you have installed.
      • +
    • type "./uninstall.sh"
      • +
    - -

    If you installed using an rpm, at a root shell prompt -type "rpm -e shorewall".

    - -

    Last updated 3/26/2001 - -Tom -Eastep

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

    If you installed using an rpm, at a root shell prompt type "rpm -e shorewall".

    + +

    Last updated 3/26/2001 - Tom Eastep

    + Copyright © 2001, 2002 Thomas M. Eastep.
    + + diff --git a/STABLE/documentation/gnu_mailman.htm b/STABLE/documentation/gnu_mailman.htm index ce43f9633..74c55a49b 100644 --- a/STABLE/documentation/gnu_mailman.htm +++ b/STABLE/documentation/gnu_mailman.htm @@ -1,78 +1,79 @@ - + - + - + - + GNU Mailman - + - - - + + - - - + + + +
    -

    GNU Mailman/Postfix the Easy + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    +

    GNU Mailman/Postfix the Easy Way

    -
    - +

     

    - -

    The following was posted on the Postfix mailing list on 5/4/2002 by Michael + +

    The following was posted on the Postfix mailing list on 5/4/2002 by Michael Tokarev as a suggested addition to the Postfix FAQ.

    - +

    Q: Mailman does not work with Postfix, complaining about GID mismatch
    -
    - A: Mailman uses a setgid wrapper that is designed to be used in system-wide - aliases file so that rest of mailman's mail handling processes will run -with proper uid/gid. Postfix has an ability to run a command specified in -an alias as owner of that alias, thus mailman's wrapper is not needed here. - The best method to invoke mailman's mail handling via aliases is to use -separate alias file especially for mailman, and made it owned by mailman +
    + A: Mailman uses a setgid wrapper that is designed to be used in system-wide + aliases file so that rest of mailman's mail handling processes will run +with proper uid/gid. Postfix has an ability to run a command specified in +an alias as owner of that alias, thus mailman's wrapper is not needed here. + The best method to invoke mailman's mail handling via aliases is to use +separate alias file especially for mailman, and made it owned by mailman and group mailman. Like:
    -
    - alias_maps = hash:/etc/postfix/aliases, hash:/var/mailman/aliases
    -
    - Make sure that /var/mailman/aliases.db is owned by mailman user (this +
    + alias_maps = hash:/etc/postfix/aliases, hash:/var/mailman/aliases
    +
    + Make sure that /var/mailman/aliases.db is owned by mailman user (this may be done by executing postalias as mailman userid).
    -
    - Next, instead of using mailman-suggested aliases entries with wrapper, +
    + Next, instead of using mailman-suggested aliases entries with wrapper, use the following:
    -
    - instead of
    - mailinglist: /var/mailman/mail/wrapper post mailinglist
    - mailinglist-admin: /var/mailman/mail/wrapper mailowner mailinglist
    - mailinglist-request: /var/mailman/mail/wrapper mailcmd mailinglist
    - ...
    -
    - use
    - mailinglist: /var/mailman/scripts/post mailinglist
    - mailinglist-admin: /var/mailman/scripts/mailowner mailinglist
    - mailinglist-request: /var/mailman/scripts/mailcmd mailinglist
    - ...

    - -

    The above tip works with Mailman 2.0; Mailman 2.1 has adopted something -very similar so that no workaround is necessary. See the README.POSTFIX file +
    + instead of
    + mailinglist: /var/mailman/mail/wrapper post mailinglist
    + mailinglist-admin: /var/mailman/mail/wrapper mailowner mailinglist
    + mailinglist-request: /var/mailman/mail/wrapper mailcmd mailinglist
    + ...
    +
    + use
    + mailinglist: /var/mailman/scripts/post mailinglist
    + mailinglist-admin: /var/mailman/scripts/mailowner mailinglist
    + mailinglist-request: /var/mailman/scripts/mailcmd mailinglist
    + ...

    + +

    The above tip works with Mailman 2.0; Mailman 2.1 has adopted something +very similar so that no workaround is necessary. See the README.POSTFIX file included with Mailman-2.1. 

    - +

    Last updated 12/29/2002 - Tom Eastep

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.

    -
    +
    +


    diff --git a/STABLE/documentation/kernel.htm b/STABLE/documentation/kernel.htm index 378e31ef9..7bfbe6cda 100644 --- a/STABLE/documentation/kernel.htm +++ b/STABLE/documentation/kernel.htm @@ -1,146 +1,165 @@ + - - -Shorewall Kernel Configuration - - + + + Shorewall Kernel Configuration + + + + - - - - - - + + +
    -

    Kernel Configuration

    -
    + + + + + +
    +

    Kernel Configuration

    +
    -

    For information regarding configuring and building GNU/Linux kernels, see http://www.kernelnewbies.org.

    + +

    For information regarding configuring and building GNU/Linux kernels, +see http://www.kernelnewbies.org.

    +

    Here's a screen shot of my Network Options Configuration:

    -
    -

     

    -
    -

    While not all of the options that I've selected are required, they should be -sufficient for most applications. Here's an excerpt from the corresponding .config -file (Note: If you are running a kernel older than 2.4.17, be sure to select -CONFIG_NETLINK and CONFIG_RTNETLINK):

    - -
    - + +
    +

      +

    +
    + +

    While not all of the options that I've selected are required, they should +be sufficient for most applications. Here's an excerpt from the corresponding +.config file (Note: If you are running a kernel older than 2.4.17, be sure +to select CONFIG_NETLINK and CONFIG_RTNETLINK):

    + +

    #
    - # Networking options
    - #
    - CONFIG_PACKET=y
    - # CONFIG_PACKET_MMAP is not set
    - # CONFIG_NETLINK_DEV is not set
    - CONFIG_NETFILTER=y
    - CONFIG_NETFILTER_DEBUG=y
    - CONFIG_FILTER=y
    - CONFIG_UNIX=y
    - CONFIG_INET=y
    - CONFIG_IP_MULTICAST=y
    - CONFIG_IP_ADVANCED_ROUTER=y
    - CONFIG_IP_MULTIPLE_TABLES=y
    - CONFIG_IP_ROUTE_FWMARK=y
    - CONFIG_IP_ROUTE_NAT=y
    - CONFIG_IP_ROUTE_MULTIPATH=y
    - CONFIG_IP_ROUTE_TOS=y
    - CONFIG_IP_ROUTE_VERBOSE=y
    - # CONFIG_IP_ROUTE_LARGE_TABLES is not set
    - # CONFIG_IP_PNP is not set
    - CONFIG_NET_IPIP=m
    - CONFIG_NET_IPGRE=m
    - # CONFIG_NET_IPGRE_GROADCAST is not set
    - # CONFIG_IP_MROUTE is not set
    - # CONFIG_ARPD is not set
    - CONFIG_INET_ECN=y
    - CONFIG_SYN_COOKIES=y

    -     -
    - + # Networking options
    + #
    + CONFIG_PACKET=y
    + # CONFIG_PACKET_MMAP is not set
    + # CONFIG_NETLINK_DEV is not set
    + CONFIG_NETFILTER=y
    + CONFIG_NETFILTER_DEBUG=y
    + CONFIG_FILTER=y
    + CONFIG_UNIX=y
    + CONFIG_INET=y
    + CONFIG_IP_MULTICAST=y
    + CONFIG_IP_ADVANCED_ROUTER=y
    + CONFIG_IP_MULTIPLE_TABLES=y
    + CONFIG_IP_ROUTE_FWMARK=y
    + CONFIG_IP_ROUTE_NAT=y
    + CONFIG_IP_ROUTE_MULTIPATH=y
    + CONFIG_IP_ROUTE_TOS=y
    + CONFIG_IP_ROUTE_VERBOSE=y
    + # CONFIG_IP_ROUTE_LARGE_TABLES is not set
    + # CONFIG_IP_PNP is not set
    + CONFIG_NET_IPIP=m
    + CONFIG_NET_IPGRE=m
    + # CONFIG_NET_IPGRE_GROADCAST is not set
    + # CONFIG_IP_MROUTE is not set
    + # CONFIG_ARPD is not set
    + CONFIG_INET_ECN=y
    + CONFIG_SYN_COOKIES=y

    +
    +

    Here's a screen shot of my Netfilter configuration:

    -
    - -

    -
    - + +
    +

    +

    +
    +

    Here's an excerpt from the corresponding .config file.

    -
    + +

    #
    - # IP: Netfilter Configuration
    - #
    - CONFIG_IP_NF_CONNTRACK=y
    - CONFIG_IP_NF_FTP=m
    - # CONFIG_IP_NF_QUEUE is not set
    - CONFIG_IP_NF_IPTABLES=y
    - CONFIG_IP_NF_MATCH_LIMIT=y
    - CONFIG_IP_NF_MATCH_MAC=y
    - CONFIG_IP_NF_MATCH_MARK=y
    - CONFIG_IP_NF_MATCH_MULTIPORT=y
    - CONFIG_IP_NF_MATCH_TOS=y
    - # CONFIG_IP_NF_MATCH_TCPMSS is not set
    - CONFIG_IP_NF_MATCH_STATE=y
    - # CONFIG_IP_NF_MATCH_UNCLEAN is not set
    - # CONFIG_IP_NF_MATCH_OWNER is not set
    - CONFIG_IP_NF_FILTER=y
    - CONFIG_IP_NF_TARGET_REJECT=y
    - # CONFIG_IP_NF_TARGET_MIRROR is not set
    - CONFIG_IP_NF_NAT=y
    - CONFIG_IP_NF_NAT_NEEDED=y
    - CONFIG_IP_NF_TARGET_MASQUERADE=y
    - CONFIG_IP_NF_TARGET_REDIRECT=y
    - CONFIG_IP_NF_NAT_FTP=m
    - CONFIG_IP_NF_MANGLE=y
    - CONFIG_IP_NF_TARGET_TOS=y
    - CONFIG_IP_NF_TARGET_MARK=y
    - CONFIG_IP_NF_TARGET_LOG=y
    - CONFIG_IP_NF_TARGET_TCPMSS=y
    - # CONFIG_IPV6 is not set
    -

    -
    -

    Note that I have built everything I need into the kernel except for the FTP -connection tracking and NAT modules. I have also run successfully with all of -the options selected above built as modules:

    - -
    -

    - + # IP: Netfilter Configuration
    + #
    + CONFIG_IP_NF_CONNTRACK=y
    + CONFIG_IP_NF_FTP=m
    + # CONFIG_IP_NF_QUEUE is not set
    + CONFIG_IP_NF_IPTABLES=y
    + CONFIG_IP_NF_MATCH_LIMIT=y
    + CONFIG_IP_NF_MATCH_MAC=y
    + CONFIG_IP_NF_MATCH_MARK=y
    + CONFIG_IP_NF_MATCH_MULTIPORT=y
    + CONFIG_IP_NF_MATCH_TOS=y
    + # CONFIG_IP_NF_MATCH_TCPMSS is not set
    + CONFIG_IP_NF_MATCH_STATE=y
    + # CONFIG_IP_NF_MATCH_UNCLEAN is not set
    + # CONFIG_IP_NF_MATCH_OWNER is not set
    + CONFIG_IP_NF_FILTER=y
    + CONFIG_IP_NF_TARGET_REJECT=y
    + # CONFIG_IP_NF_TARGET_MIRROR is not set
    + CONFIG_IP_NF_NAT=y
    + CONFIG_IP_NF_NAT_NEEDED=y
    + CONFIG_IP_NF_TARGET_MASQUERADE=y
    + CONFIG_IP_NF_TARGET_REDIRECT=y
    + CONFIG_IP_NF_NAT_FTP=m
    + CONFIG_IP_NF_MANGLE=y
    + CONFIG_IP_NF_TARGET_TOS=y
    + CONFIG_IP_NF_TARGET_MARK=y
    + CONFIG_IP_NF_TARGET_LOG=y
    + CONFIG_IP_NF_TARGET_TCPMSS=y
    + # CONFIG_IPV6 is not set
    +

    +
    + +

    Note that I have built everything I need into the kernel except for the +FTP connection tracking and NAT modules. I have also run successfully with +all of the options selected above built as modules:

    + +
    +

    +

    +

    #
    - # IP: Netfilter Configuration
    - #
    - CONFIG_IP_NF_CONNTRACK=m
    - CONFIG_IP_NF_FTP=m
    - # CONFIG_IP_NF_QUEUE is not set
    - CONFIG_IP_NF_IPTABLES=m
    - CONFIG_IP_NF_MATCH_LIMIT=m
    - CONFIG_IP_NF_MATCH_MAC=m
    - CONFIG_IP_NF_MATCH_MARK=m
    - CONFIG_IP_NF_MATCH_MULTIPORT=m
    - CONFIG_IP_NF_MATCH_TOS=m
    - # CONFIG_IP_NF_MATCH_TCPMSS is not set
    - CONFIG_IP_NF_MATCH_STATE=m
    - # CONFIG_IP_NF_MATCH_UNCLEAN is not set
    - # CONFIG_IP_NF_MATCH_OWNER is not set
    - CONFIG_IP_NF_FILTER=m
    - CONFIG_IP_NF_TARGET_REJECT=m
    - # CONFIG_IP_NF_TARGET_MIRROR is not set
    - CONFIG_IP_NF_NAT=m
    - CONFIG_IP_NF_NAT_NEEDED=m
    - CONFIG_IP_NF_TARGET_MASQUERADE=m
    - CONFIG_IP_NF_TARGET_REDIRECT=m
    - CONFIG_IP_NF_NAT_FTP=m
    - CONFIG_IP_NF_MANGLE=m
    - CONFIG_IP_NF_TARGET_TOS=m
    - CONFIG_IP_NF_TARGET_MARK=m
    - CONFIG_IP_NF_TARGET_LOG=m
    - CONFIG_IP_NF_TARGET_TCPMSS=m
    - # CONFIG_IPV6 is not set
    -

    - -
    - -

    Last updated 3/10/2002 - -Tom -Eastep

    -Copyright -© 2001, 2002 Thomas M. Eastep. + # IP: Netfilter Configuration
    + #
    + CONFIG_IP_NF_CONNTRACK=m
    + CONFIG_IP_NF_FTP=m
    + # CONFIG_IP_NF_QUEUE is not set
    + CONFIG_IP_NF_IPTABLES=m
    + CONFIG_IP_NF_MATCH_LIMIT=m
    + CONFIG_IP_NF_MATCH_MAC=m
    + CONFIG_IP_NF_MATCH_MARK=m
    + CONFIG_IP_NF_MATCH_MULTIPORT=m
    + CONFIG_IP_NF_MATCH_TOS=m
    + # CONFIG_IP_NF_MATCH_TCPMSS is not set
    + CONFIG_IP_NF_MATCH_STATE=m
    + # CONFIG_IP_NF_MATCH_UNCLEAN is not set
    + # CONFIG_IP_NF_MATCH_OWNER is not set
    + CONFIG_IP_NF_FILTER=m
    + CONFIG_IP_NF_TARGET_REJECT=m
    + # CONFIG_IP_NF_TARGET_MIRROR is not set
    + CONFIG_IP_NF_NAT=m
    + CONFIG_IP_NF_NAT_NEEDED=m
    + CONFIG_IP_NF_TARGET_MASQUERADE=m
    + CONFIG_IP_NF_TARGET_REDIRECT=m
    + CONFIG_IP_NF_NAT_FTP=m
    + CONFIG_IP_NF_MANGLE=m
    + CONFIG_IP_NF_TARGET_TOS=m
    + CONFIG_IP_NF_TARGET_MARK=m
    + CONFIG_IP_NF_TARGET_LOG=m
    + CONFIG_IP_NF_TARGET_TCPMSS=m
    + # CONFIG_IPV6 is not set
    +

    +
    + +

    Last updated 3/10/2002 - Tom Eastep

    + Copyright © 2001, 2002 Thomas M. Eastep.
    + + diff --git a/STABLE/documentation/mailing_list.htm b/STABLE/documentation/mailing_list.htm index bbe056d61..8a4453199 100644 --- a/STABLE/documentation/mailing_list.htm +++ b/STABLE/documentation/mailing_list.htm @@ -1,153 +1,148 @@ - + - + - + - + Shorewall Mailing Lists - + - - - - - + - + - - - - +
    + + + + +
    +
    - +

    Vexira Logo -

    - + - - + +

      (Razor Logo) -

    -     		- +

    +     		+

    Shorewall Mailing Lists

    -     		- + + (Postfix Logo) -
    - +
    + + -
    - + +
    + +

    -
    -
    -
    - +

    REPORTING A PROBLEM OR ASKING FOR HELP? If you haven't already, please - read the Shorewall Support - Guide.
    -

    - + read the Shorewall Support + Guide.
    + +

    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 tmeastep at hotmail dot com.

    - +

    A Word about the SPAM Filters at Shorewall.net 

    - +

    Please note that the mail server at shorewall.net checks incoming mail:
    -

    - +

    +
      -
    1. against against Spamassassin (including Vipul's Razor).
      -
      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 that resolves.
      5. -
    5. to ensure that the sending system has a valid PTR record in DNS.
      6. - + +
    6. to ensure that the sender address is fully + qualified.
      7. +
    7. to verify that the sender's domain has +an A or MX record in DNS.
      8. +
    8. to ensure that the host name in the HELO/EHLO + command is a valid fully-qualified DNS name that resolves.
      9. +
    -This last point is important. If you run your -own outgoing mail server and it doesn't have a valid DNS PTR record, your -email won't reach the lists unless/until the postmaster notices that your -posts are being rejected. To avoid this problem, you should configure your -MTA to forward posts to shorewall.net through an MTA that does have -a valid PTR record (such as the one at your ISP).
    - +

    Please post in plain text

    - A growing number of MTAs serving list subscribers are -rejecting all HTML traffic. At least one MTA has gone so far as to -blacklist shorewall.net "for continuous abuse" because it has been my -policy to allow HTML in list posts!!
    -
    - I think that blocking all HTML is a Draconian way to -control spam and that the ultimate losers here are not the spammers -but the list subscribers whose MTAs are bouncing all shorewall.net -mail. As one list subscriber wrote to me privately "These e-mail admin's -need to get a (explitive deleted) life instead of trying to rid -the planet of HTML based e-mail". Nevertheless, to allow subscribers + A growing number of MTAs serving list subscribers are + rejecting all HTML traffic. At least one MTA has gone so far as to + blacklist shorewall.net "for continuous abuse" because it has been +my policy to allow HTML in list posts!!
    +
    + I think that blocking all HTML is a Draconian way to + control spam and that the ultimate losers here are not the spammers + but the list subscribers whose MTAs are bouncing all shorewall.net + mail. As one list subscriber wrote to me privately "These e-mail admin's + need to get a (explitive deleted) life instead of trying to rid + the planet of HTML based e-mail". Nevertheless, to allow subscribers to receive list posts as must as possible, I have now configured the list server at shorewall.net to strip all HTML from outgoing posts. This means that HTML-only posts will be bounced by the list server.
    - +

    Note: The list server limits posts to 120kb.
    -

    - +

    +

    Other Mail Delivery Problems

    - If you find that you are missing an occasional list post, - your e-mail admin may be blocking mail whose Received: headers - contain the names of certain ISPs. Again, I believe that such policies - hurt more than they help but I'm not prepared to go so far as to start - stripping Received: headers to circumvent those policies.
    - + If you find that you are missing an occasional list post, + your e-mail admin may be blocking mail whose Received: headers + contain the names of certain ISPs. Again, I believe that such policies + hurt more than they help but I'm not prepared to go so far as to start + stripping Received: headers to circumvent those policies.
    +

    Mailing Lists Archive Search

    - +
    - -

    Match: + +

    Match: - Format: + Format: - Sort by: + Sort by: -
    - Search:

    - - + +

    Please do not try to download the entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't stand the traffic. If I catch you, you will be blacklisted.
    -

    - +
    +

    Shorewall CA Certificate

    - If you want to trust X.509 certificates issued - by Shoreline Firewall (such as the one used on my web site), + 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 + 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 + 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:
    -

    - +

    + - +

    To post to the list, post to shorewall-users@lists.shorewall.net.

    - +

    The list archives are at http://lists.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:
    -

    - + Shorewall community. To subscribe:
    +

    +

    - + - +


    - The list archives are at http://lists.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:
    -

    - +

    + - +

    To post to the list, post to shorewall-devel@lists.shorewall.net. 

    - +

    The list archives are at http://lists.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 although Mailman 2.1 has attempted - to make this less confusing. To unsubscribe:

    - + from Mailman-managed lists although Mailman 2.1 has attempted + to make this less confusing. 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 unsubscribe from <list name>, get - a password reminder, or change your subscription options enter - your subscription email address:". Enter your email address - in the box and click on the "Unsubscribe or edit options" - button.

      -
      • -
    • - + " To unsubscribe from <list name>, get + a password reminder, or change your subscription options +enter your subscription email address:". Enter your email + address in the box and click on the "Unsubscribe or 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 6/14/2003 - Last updated 7/7/2003 - Tom Eastep

    - +

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

    +

    +
    +
    diff --git a/STABLE/documentation/myfiles.htm b/STABLE/documentation/myfiles.htm index ad126154b..90dbecc1d 100644 --- a/STABLE/documentation/myfiles.htm +++ b/STABLE/documentation/myfiles.htm @@ -1,238 +1,247 @@ - + My Shorewall Configuration - + + - + - + - + - - - + + - - - + + + +
    - + bgcolor="#3366ff" height="90"> +
    +

    About My Network

    -
    - +
    - +

    My Current Network

    - -
    + +

    Warning 1: I - use a combination of Static NAT and Proxy ARP, neither of which are relevant - to a simple configuration with a single public IP address. - If you have just a single public IP address, most of what you see here - won't apply to your setup so beware of copying parts of this configuration - and expecting them to work for you. What you copy may or may not work in - your configuration.
    -

    - -

    Warning 2: My - configuration uses features introduced in Shorewall version 1.4.4b.
    -

    - + use a combination of Static NAT and Proxy ARP, neither of which are + relevant to a simple configuration with a single public IP address.     + If you have just a single public IP address, most of what you see here + won't apply to your setup so beware of copying parts of this configuration + and expecting them to work for you. What you copy may or may not work + in your configuration.
    +

    + +

    Warning 2: The +configuration shown here corresponds to Snapshot 1.4.5_20030629 plus a couple +of patches.
    +

    +

    I have DSL service and have 5 static IP addresses (206.124.146.176-180). - My DSL "modem" (Fujitsu Speedport) - is connected to eth0. I have a local network connected to eth2 (subnet - 192.168.1.0/24), a DMZ connected to eth1 (192.168.2.0/24) and a Wireless - network connected to eth3 (192.168.3.0/24).

    - + My DSL "modem" (Fujitsu +Speedport) is connected to eth0. I have a local network connected +to eth2 (subnet 192.168.1.0/24), a DMZ connected to eth1 (192.168.2.0/24) +and a Wireless network connected to eth3 (192.168.3.0/24).

    +

    I use:
    -

    - +

    +
      -
    • Static NAT for Ursa (my XP System) - Internal address - 192.168.1.5 and external address 206.124.146.178.
      • -
    • Static NAT for Wookie (my Linux System). Internal - address 192.168.1.3 and external address 206.124.146.179.
      • -
    • Static NAT for EastepLaptop (My work system). Internal address -192.168.1.7 and external address 206.124.146.180.
      -
      • -
    • SNAT through the primary gateway address (206.124.146.176) - for  my Wife's system (Tarry) and our  laptop (Tipper) which connects - through the Wireless Access Point (wap) via a Wireless Bridge (bridge). -
      -
      - Note:       While the distance between the WAP and where I usually use -the laptop isn't very far (25 feet or so), using a WAC11 (CardBus wireless -card) has proved very unsatisfactory (lots of lost connections). By replacing -the WAC11 with the WET11 wireless bridge, I have virtually eliminated these -problems (Being an old radio tinkerer (K7JPV), I was also able to eliminate -the disconnects by hanging a piece of aluminum foil on the family room wall. -Needless to say, my wife Tarry rejected that as a permanent solution :-).
      • - +
    • Static NAT for Ursa (my XP System) - Internal + address 192.168.1.5 and external address 206.124.146.178.
      • +
    • Static NAT for Wookie (my Linux System). Internal + address 192.168.1.3 and external address 206.124.146.179.
      • +
    • Static NAT for EastepLaptop (My work system). Internal address + 192.168.1.7 and external address 206.124.146.180.
      +
      • +
    • SNAT through the primary gateway address (206.124.146.176) + for  my Wife's system (Tarry) and our  laptop (Tipper) which connects + through the Wireless Access Point (wap) via a Wireless Bridge (bridge). +
      +
      + Note:       While the distance between the WAP and where I usually +use the laptop isn't very far (25 feet or so), using a WAC11 (CardBus +wireless card) has proved very unsatisfactory (lots of lost connections). +By replacing the WAC11 with the WET11 wireless bridge, I have virtually +eliminated these problems (Being an old radio tinkerer (K7JPV), I was also +able to eliminate the disconnects by hanging a piece of aluminum foil on +the family room wall. Needless to say, my wife Tarry rejected that as a +permanent solution :-).
      • +
    - +

    The firewall runs on a 256MB PII/233 with RH9.0.

    - -

    Wookie and the Firewall both run Samba and the Firewall acts as the -a WINS server.
    -

    - + +

    Wookie and the Firewall both run Samba and the Firewall acts as a WINS +server.
    +

    +

    Wookie is in its own 'whitelist' zone called 'me' which is embedded in the local zone.

    - +

    The wireless network connects to eth3 via a LinkSys WAP11.  In additional - to using the rather weak WEP 40-bit encryption (64-bit with the 24-bit prefix), - I use MAC verification. This is still a - weak combination and if I lived near a wireless "hot spot", I would probably - add IPSEC or something similar to my WiFi->local connections.
    -

    - + to using the rather weak WEP 40-bit encryption (64-bit with the 24-bit +prefix), I use MAC verification. This +is still a weak combination and if I lived near a wireless "hot spot", I +would probably add IPSEC or something similar to my WiFi->local connections.
    +

    +

    The single system in the DMZ (address 206.124.146.177) runs postfix, - Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an -FTP server (Pure-ftpd). The system also runs fetchmail to fetch our -email from our old and current ISPs. That server is managed through -Proxy ARP.

    - + Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an + FTP server (Pure-ftpd). The system also runs fetchmail to fetch +our email from our old and current ISPs. That server is managed through + Proxy ARP.

    +

    The firewall system itself runs a DHCP server that serves the local - network. It also runs Postfix which is configured as a Virus and - Spam filter with all incoming mail then being forwarded to the MTA in the - DMZ.

    - + network. It also runs Postfix which is configured as a Virus and + Spam filter with all incoming mail then being forwarded to the MTA in +the DMZ.

    +

    All administration and publishing is done using ssh/scp. I have X installed - on the firewall but no X server or desktop is installed. X applications -tunnel through SSH to XWin.exe running on Ursa. The server does have a desktop -environment installed and that desktop environment is available via XDMCP -from the local zone. For the most part though, X tunneled through SSH is -used for server administration and the server runs at run level 3 (multi-user -console mode on RedHat).

    - + on the firewall but no X server or desktop is installed. X applications + tunnel through SSH to XWin.exe running on Ursa. The server does have a +desktop environment installed and that desktop environment is available +via XDMCP from the local zone. For the most part though, X tunneled through +SSH is used for server administration and the server runs at run level 3 +(multi-user console mode on RedHat).

    +

    I run an SNMP server on my firewall to serve MRTG running - in the DMZ.

    - + in the DMZ.

    +

    (My network layout) -

    - -

     

    - -

    The ethernet interface in the Server is configured with IP address - 206.124.146.177, netmask 255.255.255.0. The server's default gateway - is 206.124.146.254 (Router at my ISP. This is the same default - gateway used by the firewall itself). On the firewall, - Shorewall automatically adds a host route to - 206.124.146.177 through eth1 (192.168.2.1) because of - the entry in /etc/shorewall/proxyarp (see below).

    +

    +

     

    + +

    The ethernet interface in the Server is configured with IP address + 206.124.146.177, netmask 255.255.255.0. The server's default gateway + is 206.124.146.254 (Router at my ISP. This is the same +default gateway used by the firewall itself). On the firewall, + Shorewall automatically adds a host route to + 206.124.146.177 through eth1 (192.168.2.1) because + of the entry in /etc/shorewall/proxyarp (see + below).

    +

    Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior - access.
    -

    - + access.
    +

    +

    -
    - +
    +

    Shorewall.conf

    - -
    - 
    LOGFILE=/var/log/messages
    LOGRATE=
    LOGBURST=
    LOGUNCLEAN=$LOG
    BLACKLIST_LOGLEVEL=
    LOGNEWNOTSYN=
    MACLIST_LOG_LEVEL=$LOG
    TCP_FLAGS_LOG_LEVEL=$LOG
    RFC1918_LOG_LEVEL=$LOG
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
    SUBSYSLOCK=/var/lock/subsys/shorewall
    STATEDIR=/var/state/shorewall
    MODULESDIR=
    FW=fw
    NAT_ENABLED=Yes
    MANGLE_ENABLED=Yes
    IP_FORWARDING=On
    ADD_IP_ALIASES=Yes
    ADD_SNAT_ALIASES=Yes
    TC_ENABLED=Yes
    CLEAR_TC=No
    MARK_IN_FORWARD_CHAIN=No
    CLAMPMSS=Yes
    ROUTE_FILTER=No
    NAT_BEFORE_RULES=No
    MULTIPORT=Yes
    DETECT_DNAT_IPADDRS=Yes
    MUTEX_TIMEOUT=60
    NEWNOTSYN=Yes
    BLACKLIST_DISPOSITION=DROP
    MACLIST_DISPOSITION=REJECT
    TCP_FLAGS_DISPOSITION=DROP
    SHARED_DIR=/usr/share/shorewall
    -
    - + +
    + 
    LOGFILE=/var/log/messages
    LOGRATE=
    LOGBURST=
    LOGUNCLEAN=$LOG
    BLACKLIST_LOGLEVEL=
    LOGNEWNOTSYN=
    MACLIST_LOG_LEVEL=$LOG
    TCP_FLAGS_LOG_LEVEL=$LOG
    RFC1918_LOG_LEVEL=$LOG
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
    SHOREWALL_SHELL=/bin/ash
    SUBSYSLOCK=/var/lock/subsys/shorewall
    STATEDIR=/var/state/shorewall
    MODULESDIR=
    FW=fw
    IP_FORWARDING=On
    ADD_IP_ALIASES=Yes
    ADD_SNAT_ALIASES=Yes
    TC_ENABLED=Yes
    CLEAR_TC=No
    MARK_IN_FORWARD_CHAIN=No
    CLAMPMSS=Yes
    ROUTE_FILTER=No
    NAT_BEFORE_RULES=No
    DETECT_DNAT_IPADDRS=Yes
    MUTEX_TIMEOUT=60
    NEWNOTSYN=Yes
    BLACKLIST_DISPOSITION=DROP
    MACLIST_DISPOSITION=REJECT
    TCP_FLAGS_DISPOSITION=DROP
    SHARED_DIR=/usr/share/shorewall
    +
    +

    Params File (Edited):

    - -
    + +
    MIRRORS=<list of shorewall mirror ip addresses>
    NTPSERVERS=<list of the NTP servers I sync with>
 TEXAS=<ip address of gateway in Dallas>
    LOG=info
    -
    - +
    +

    Zones File

    - -
    + +
    #ZONE	DISPLAY		COMMENTS
    net     Internet        Internet
    WiFi    Wireless        Wireless Network on eth3
    me      Wookie          My Linux Workstation
    dmz     DMZ             Demilitarized zone
    loc     Local           Local networks
    tx      Texas           Peer Network in Dallas
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Interfaces File:

    - -
    + +

    This is set up so that I can start the firewall before bringing up my Ethernet interfaces.

    -
    - -
    +
    + +
    #ZONE	INERFACE	BROADCAST	OPTIONS
    net     eth0            206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
    loc     eth2            192.168.1.255   dhcp
    dmz     eth1            192.168.2.255
    WiFi    eth3            192.168.3.255   dhcp,maclist
    -       texas           192.168.9.255
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Hosts File:

    - -
    + +
    #ZONE		HOST(S)			OPTIONS
    me              eth2:192.168.1.3
    tx              texas:192.168.8.0/22
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Routestopped File:

    - -
    + +
    #INTERFACQ	HOST(S)
    eth1            206.124.146.177
    eth2            -
    eth3            192.168.3.8
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Policy File:

    - -
    + +
    #SOURCE		DESTINATION	POLICY		LOG LEVEL	BURST:LIMIT
    me              loc             NONE
    me              all             ACCEPT
    tx              me              ACCEPT
    WiFi            loc             ACCEPT
    loc             WiFi            ACCEPT
    loc             me              NONE
    all             me              CONTINUE        -               2/sec:5
    loc             net             ACCEPT
    $FW             loc             ACCEPT
    $FW             tx              ACCEPT
    loc             tx              ACCEPT
    loc             fw              REJECT          $LOG
    WiFi            net             ACCEPT
    net             all             DROP            $LOG            10/sec:40
    all             all             REJECT          $LOG
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Masq File:

    - -
    + +

    Although most of our internal systems use static NAT, my wife's system - (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors - with laptops. Also, I masquerade systems connected through the wireless - network.

    -
    - -
    + (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors + with laptops. Also, I masquerade systems connected through the wireless + network.

    +
    + +
    #INTERFACE              SUBNET          ADDRESS
    eth0                    eth2            206.124.146.176
    eth0                    eth3            206.124.146.176
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    - +
    +

    NAT File:

    - -
    + +
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    206.124.146.178 eth0:0          192.168.1.5     No                      No
    206.124.146.179 eth0:1          192.168.1.3     No                      No
    206.124.146.180 eth0:2          192.168.1.7     No                      No
    192.168.1.193   eth2:0          206.124.146.177 No                      No
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE\
    -
    - +
    +

    Proxy ARP File:

    - -
    + +
    #ADDRESS                INTERFACE       EXTERNAL        HAVEROUTE
    206.124.146.177         eth1            eth0            No
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - +
    +

    Tunnels File (Shell variable TEXAS set in /etc/shorewall/params):

    - -
    + +
    #TYPE			ZONE    GATEWAY         GATEWAY ZONE    PORT
    gre                     net     $TEXAS
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - +
    +

    - +

    Rules File (The shell variables are set in /etc/shorewall/params):

    - -
    + +
    ################################################################################################################################################################
    #RESULT         CLIENT(S)                       SERVER(S)               PROTO   PORT(S)                                 CLIENT          ORIGINAL DEST:SNAT
    ################################################################################################################################################################
    # Local Network to Internet - Reject attempts by Trojans to call home
    #
    REJECT:$LOG     loc                             net                     tcp     6667
    #
    # Stop NETBIOS crap since our policy is ACCEPT
    #
    REJECT          loc                             net                     tcp     137,445
    REJECT          loc                             net                     udp     137:139
    ################################################################################################################################################################
    # Local Network to Firewall
    #
    DROP            loc:!192.168.1.0/24             fw
    ACCEPT          loc                             fw                      tcp     ssh,time,10000,smtp,swat,137,139,445
    ACCEPT          loc                             fw                      udp     snmp,ntp,445
    ACCEPT          loc                             fw                      udp     137:139
    ACCEPT          loc                             fw                      udp     1024:                                   137
    ################################################################################################################################################################
    # Local Network to DMZ
    #
    ACCEPT          loc                             dmz                     udp     domain,xdmcp
    ACCEPT          loc                             dmz                     tcp     www,smtp,domain,ssh,imap,https,imaps,cvspserver,ftp,10000,8080,pop3     -
    ################################################################################################################################################################
    # Internet to DMZ
    #
    ACCEPT          net                             dmz                     tcp     www,ftp,imaps,domain,cvspserver,https   -
    ACCEPT          net                             dmz                     udp     domain
    ACCEPT          net:$MIRRORS                    dmz                     tcp     rsync
    ACCEPT:$LOG     net                             dmz                     tcp     32768:61000                             20
    DROP            net                             dmz                     tcp     1433
    ################################################################################################################################################################
    #
    # Net to Local
    #
    # When I'm "on the road", the following two rules allow me VPN access back home.
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     1723
    ACCEPT          net                             loc:192.168.1.5         gre
    #
    # ICQ
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     4000:4100
    #
    # Real Audio
    #
    ACCEPT          net                             loc:192.168.1.5         udp     6790
    ################################################################################################################################################################
    # Net to me
    #
    ACCEPT          net                             loc:192.168.1.3         tcp     4000:4100
    ################################################################################################################################################################
    # DMZ to Internet
    #
    ACCEPT          dmz                             net                     tcp     smtp,domain,www,https,whois,echo,2702,21,2703,ssh
    ACCEPT          dmz                             net                     udp     domain
    #ACCEPT         dmz                             net:$POPSERVERS         tcp     pop3
    #ACCEPT         dmz                             net:206.191.151.2       tcp     pop3
    #ACCEPT         dmz                             net:66.216.26.115       tcp     pop3
    #
    # Something is wrong with the FTP connection tracking code or there is some client out there
    # that is sending a PORT command which that code doesn't understand. Either way,
    # the following works around the problem.
    #
    ACCEPT:$LOG     dmz                             net                     tcp     1024:                                   20
    ################################################################################################################################################################
    # DMZ to Firewall -- ntp & snmp, Silently reject Auth
    #
    ACCEPT          dmz                             fw                      udp     ntp                                     ntp
    ACCEPT          dmz                             fw                      tcp     snmp,ssh
    ACCEPT          dmz                             fw                      udp     snmp
    REJECT          dmz                             fw                      tcp     auth
    ################################################################################################################################################################
    #
    # DMZ to Local Network
    #
    ACCEPT          dmz                             loc                     tcp     smtp,6001:6010
    ################################################################################################################################################################
    #
    # DMZ to Me -- NFS
    #
    ACCEPT          dmz                             me                      tcp     111
    ACCEPT          dmz                             me                      udp     111
    ACCEPT          dmz                             me                      udp     2049
    ACCEPT          dmz                             me                      udp     32700:
    ################################################################################################################################################################
    # Internet to Firewall
    #
    REDIRECT-       net                             25                      tcp     smtp                                    -               206.124.146.177
    ACCEPT          net                             fw                      tcp     smtp
    REJECT          net                             fw                      tcp     www
    DROP            net                             fw                      tcp     1433
    ################################################################################################################################################################
    # WiFi to Firewall (SMB and NTP)
    #
    ACCEPT          WiFi                            fw                      tcp     ssh,137,139,445
    ACCEPT          WiFi                            fw                      udp     137:139,445
    ACCEPT          WiFi                            fw                      udp     1024:                                   137
    ACCEPT          WiFi                            fw                      udp     ntp                                     ntp
    ################################################################################################################################################################
    # Firewall to WiFi (SMB)
    #
    ACCEPT          fw                              WiFi                    tcp     137,139,445
    ACCEPT          fw                              WiFi                    udp     137:139,445
    ACCEPT          fw                              WiFi                    udp     1024:                                   137
    ###############################################################################################################################################################
    # WiFi to DMZ
    #
    DNAT-           WiFi                            dmz:206.124.146.177     all     -                                       -               192.168.1.193
    ACCEPT          WiFi                            dmz                     tcp     smtp,www,ftp,imaps,domain,https,ssh     -
    ACCEPT          WiFi                            dmz                     udp     domain
    ################################################################################################################################################################
    # Firewall to Internet
    #
    ACCEPT          fw                              net:$NTPSERVERS         udp     ntp                                     ntp
    ACCEPT          fw                              net:$POPSERVERS         tcp     pop3
    ACCEPT          fw                              net                     udp     domain
    ACCEPT          fw                              net                     tcp     domain,www,https,ssh,1723,whois,1863,smtp,ftp,2702,2703,7
    ACCEPT          fw                              net                     udp     33435:33535
    ACCEPT          fw                              net                     icmp    8
    ################################################################################################################################################################
    # Firewall to DMZ
    #
    ACCEPT          fw                              dmz                     tcp     www,ftp,ssh,smtp
    ACCEPT          fw                              dmz                     udp     domain
    ACCEPT          fw                              dmz                     icmp    8
    REJECT          fw                              dmz                     udp     137:139

    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - -

    Tom Eastep

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

    Last updated 6/30/2003 - Tom Eastep +

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

    diff --git a/STABLE/documentation/ping.html b/STABLE/documentation/ping.html index 47e4a6e2c..6465ea851 100644 --- a/STABLE/documentation/ping.html +++ b/STABLE/documentation/ping.html @@ -2,191 +2,190 @@ ICMP Echo-request (Ping) - + - + - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    ICMP Echo-request (Ping)

    -
    -
    - Shorewall 'Ping' management has evolved over time with the latest change - coming in Shorewall version 1.4.0.
    - +
    + Shorewall 'Ping' management has evolved over time with the latest +change coming in Shorewall version 1.4.0. To find out which version of +Shorewall you are running, at a shell prompt type "/sbin/shorewall +version". If that command gives you an error, it's time to upgrade +since you have a very old version of Shorewall installed (1.2.4 or earlier).
    +

    Shorewall Versions >= 1.4.0

    -In Shoreall 1.4.0 and later version, ICMP echo-request's are treated just -like any other connection request.
    -
    - In order to accept ping requests from zone z1 to zone z2 where the policy -for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the -form:
    - -
    ACCEPT    z1    z2    - icmp    8
    -
    - Example:
    -
    - To permit ping from the local zone to the firewall:
    - -
    ACCEPT    loc    fw    - icmp    8
    -
    - If you would like to accept 'ping' by default even when the relevant - policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't - already exist and in that file place the following command:
    - -
    - 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    -
    - With that rule in place, if you want to ignore 'ping' from z1 to z2 then - you need a rule of the form:
    - -
    DROP    z1    z2    - icmp    8
    -
    - Example:
    -
    - To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    + In Shoreall 1.4.0 and later version, ICMP echo-request's are treated just + like any other connection request.

    - -
    DROP    net    fw    - icmp    8
    -
    - -

    Shorewall Versions >= 1.3.14  and < 1.4.0 with OLD_PING_HANDLING=No -in /etc/shorewall/shorewall.conf

    - In 1.3.14, Ping handling was put under control of the rules and policies - just like any other connection request. In order to accept ping requests -from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you -need a rule in /etc/shoreall/rules of the form:
    - + In order to accept ping requests from zone z1 to zone z2 where the policy + for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the + form:
    +
    ACCEPT    z1    z2    - icmp    8
    -
    - Example:
    -
    - To permit ping from the local zone to the firewall:
    - -
    ACCEPT    loc    fw    - icmp    8
    -
    - If you would like to accept 'ping' by default even when the relevant - policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't - already exist and in that file place the following command:
    - -
    - 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    -
    - With that rule in place, if you want to ignore 'ping' from z1 to z2 then - you need a rule of the form:
    - -
    DROP    z1    z2    - icmp    8
    -
    - Example:
    -
    - To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    - -
    DROP    net    fw    - icmp    8
    -
    - -
    - -

    Shorewall Versions < 1.3.14 or with OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
    -

    - There are several aspects to the old 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 5/4/2003 - Tom Eastep -

    - -

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

    + icmp    8
    + + Example:

    -
    + To permit ping from the local zone to the firewall:
    + +
    ACCEPT    loc    fw    + icmp    8
    +
    + If you would like to accept 'ping' by default even when the relevant + policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't + already exist and in that file place the following command:
    + +
    + 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    +
    + With that rule in place, if you want to ignore 'ping' from z1 to z2 +then you need a rule of the form:
    + +
    DROP    z1    z2    + icmp    8
    +
    + Example:
    +
    + To drop ping from the internet, you would need this rule in /etc/shorewall/rules:

    -
    -
    + +
    DROP    net    fw    + icmp    8
    +
    + +

    Shorewall Versions >= 1.3.14  and < 1.4.0 with OLD_PING_HANDLING=No + in /etc/shorewall/shorewall.conf

    + In 1.3.14, Ping handling was put under control of the rules and policies + just like any other connection request. In order to accept ping requests + from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you + need a rule in /etc/shoreall/rules of the form:
    + +
    ACCEPT    z1    z2    + icmp    8
    +
    + Example:
    +
    + To permit ping from the local zone to the firewall:
    + +
    ACCEPT    loc    fw    + icmp    8
    +
    + If you would like to accept 'ping' by default even when the relevant + policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't + already exist and in that file place the following command:
    + +
    + 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    +
    + With that rule in place, if you want to ignore 'ping' from z1 to z2 +then you need a rule of the form:
    + +
    DROP    z1    z2    + icmp    8
    +
    + Example:
    +
    + To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    + +
    DROP    net    fw    + icmp    8
    +
    + +
    + +

    Shorewall Versions < 1.3.14 or with OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
    +

    + There are several aspects to the old 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 7/7/2003 - Tom Eastep +

    + +

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


    diff --git a/STABLE/documentation/ports.htm b/STABLE/documentation/ports.htm index 8b23480e1..7af0cba5a 100644 --- a/STABLE/documentation/ports.htm +++ b/STABLE/documentation/ports.htm @@ -1,240 +1,242 @@ - + Shorewall Port Information - + - + - + - - - + + - - - + Services/Applications + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Ports required for Various - Services/Applications

    -
    - +

    In addition to those applications described in the /etc/shorewall/rules documentation, here - are some other services/applications that you may need to configure your - firewall to accommodate.

    - + are some other services/applications that you may need to configure your + firewall to accommodate.

    +

    NTP (Network Time Protocol)

    - -
    + +

    UDP Port 123

    -
    - +
    +

    rdate

    - -
    + +

    TCP Port 37

    -
    - +
    +

    UseNet (NNTP)

    - -
    + +

    TCP Port 119

    -
    - +
    +

    DNS

    - -
    + +

    UDP Port 53. If you are configuring a DNS client, you will probably want to open TCP Port 53 as well.
    - If you are configuring a server, only open TCP Port 53 if you will - return long replies to queries or if you need to enable ZONE transfers. In - the latter case, be sure that your server is properly configured.

    -
    - + If you are configuring a server, only open TCP Port 53 if you +will return long replies to queries or if you need to enable ZONE transfers. In + the latter case, be sure that your server is properly configured.

    +
    +

    ICQ   

    - -
    + +

    UDP Port 4000. You will also need to open a range of TCP ports which - you can specify to your ICQ client. By default, clients use 4000-4100.

    -
    - + you can specify to your ICQ client. By default, clients use 4000-4100.

    +
    +

    PPTP

    - -
    + +

    Protocol 47 (NOT port 47) and TCP Port 1723 (Lots more information here).

    -
    - +
    +

    IPSEC

    - -
    + +

    Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port - 500. These should be opened in both directions (Lots more information - here and here).

    -
    - -

    SMTP

    - -
    + 500. These should be opened in both directions (Lots more information + here and here).

    +
    + +

    SMTP (Email)

    + +

     TCP Port 25.

    -
    - +
    +

    RealPlayer
    -

    -
    +

    + +

    UDP Port 6790 inbound
    +

    +
    + +

    POP3

    + +
    +

    TCP Port 110 (Secure = TCP Port 995)

    -

    POP3

    - -
    -

    TCP Port 110.

    -
    - +

    IMAP
    +

    +
    TCP Port 143 (Secure = TCP Port 993)
    +
    +

    TELNET

    - -
    + +

    TCP Port 23.

    -
    - +
    +

    SSH

    - -
    + +

    TCP Port 22.

    -
    - +
    +

    Auth (identd)

    - -
    + +

    TCP Port 113

    -
    - +
    +

    Web Access

    - -
    + +

    TCP Ports 80 and 443.

    -
    - +
    +

    FTP

    - -
    + +

    Server configuration is covered on in the /etc/shorewall/rules documentation,

    - +

    For a client, you must open outbound TCP port 21 and be sure that your - kernel is compiled to support FTP connection tracking. If you build this - support as a module, Shorewall will automatically load the module from - /var/lib/<kernel version>/kernel/net/ipv4/netfilter. 
    -

    - -

    If you run an FTP server on a nonstandard port or you need to access - such a server, then you must specify that port in /etc/shorewall/modules. - For example, if you run an FTP server that listens on port 49 then you would - have:
    -

    - -
    -

    loadmodule ip_conntrack_ftp ports=21,49
    - loadmodule ip_nat_ftp ports=21,49
    + kernel is compiled to support FTP connection tracking. If you build +this support as a module, Shorewall will automatically load the module +from /var/lib/<kernel version>/kernel/net/ipv4/netfilter. 

    -
    - + +

    If you run an FTP server on a nonstandard port or you need to access + such a server, then you must specify that port in /etc/shorewall/modules. + For example, if you run an FTP server that listens on port 49 then you +would have:
    +

    + +
    +

    loadmodule ip_conntrack_ftp ports=21,49
    + loadmodule ip_nat_ftp ports=21,49
    +

    +
    +

    Note that you MUST include port 21 in the ports list or you may - have problems accessing regular FTP servers.

    - + have problems accessing regular FTP servers.

    +

    If there is a possibility that these modules might be loaded before Shorewall starts, then you should include the port list in /etc/modules.conf:
    -

    - -
    +

    + +

    options ip_conntrack_ftp ports=21,49
    - options ip_nat_ftp ports=21,49
    -

    -
    - + options ip_nat_ftp ports=21,49
    +

    +
    +

    IMPORTANT: Once you have made these changes to /etc/shorewall/modules - and/or /etc/modules.conf, you must either:
    -

    - -
      -
    1. Unload the modules and restart shorewall: (rmmod ip_nat_ftp; rmmod ip_conntrack_ftp; shorewall restart); - or
      2. -
    2. Reboot
      -
      3. - -
    - -

    -
    - -
    - -

    SMB/NMB (Samba/Windows Browsing/File Sharing)

    - -
    - -
    -

    TCP Ports 137, 139 and 445.
    - UDP Ports 137-139.
    -
    - Also, see this page.

    -
    - -

    Traceroute

    - -
    -

    UDP ports 33434 through 33434+<max number of hops>-1

    -
    - -

    NFS
    -

    - -
    -

    I personally use the following rules for opening access from zone z1 - to a server with IP address a.b.c.d in zone z2:
    + and/or /etc/modules.conf, you must either:

    - + +
      +
    1. Unload the modules and restart shorewall: (rmmod ip_nat_ftp; rmmod ip_conntrack_ftp; shorewall restart); + or
      2. +
    2. Reboot
      +
      3. + +
    + +

    +
    + +
    + +

    SMB/NMB (Samba/Windows Browsing/File Sharing)

    + +
    + +
    +

    TCP Ports 137, 139 and 445.
    + UDP Ports 137-139.
    +
    + Also, see this page.

    +
    + +

    Traceroute

    + +
    +

    UDP ports 33434 through 33434+<max number of hops>-1
    +ICMP type 8 ('ping')
    +

    +
    + +

    NFS
    +

    + +
    +

    I personally use the following rules for opening access from zone z1 + to a server with IP address a.b.c.d in zone z2:
    +

    + 
    ACCEPT	z1	z2:a.b.c.d	udp	111
    ACCEPT	z1	z2:a.b.c.d	tcp	111
    ACCEPT	z1	z2:a.b.c.d	udp	2049
    ACCEPT	z1	z2:a.b.c.d	udp	32700:
    -
    - -
    +
    + +

    Note that my rules only cover NFS using UDP (the normal case). There - is lots of additional information at  http://nfs.sourceforge.net/nfs-howto/security.html

    -
    - +
    +

    VNC
    -

    - -
    +

    + +

    TCP port 5900 + <display number>

    -
    - +
    +

    Didn't find what you are looking for -- have you looked in your own /etc/services - file?

    - + file?

    +

    Still looking? Try http://www.networkice.com/advice/Exploits/Ports

    - -

    Last updated 5/5/2003 - Last updated 7/16/2003 - Tom Eastep

    - Copyright © Copyright © 2001, 2002, 2003 Thomas M. Eastep.
    -
    -
    -
    -
    -
    -
    -
    diff --git a/STABLE/documentation/quotes.htm b/STABLE/documentation/quotes.htm index c38f3c18d..cb5f4bcf9 100644 --- a/STABLE/documentation/quotes.htm +++ b/STABLE/documentation/quotes.htm @@ -1,108 +1,117 @@ - + - + - + - + Quotes from Shorewall Users - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Quotes from Shorewall Users

    -
    - + "I have fought with IPtables for untold hours. First I +tried the SuSE firewall, which worked for 80% of what I needed. Then gShield, +which also worked for 80%. Then I set out to write my own IPtables parser +in shell and awk, which was a lot of fun but never got me past the "hey, +cool" stage. Then I discovered Shorewall. After about an hour, everything +just worked. I am stunned, and very grateful" -- ES, Phoenix AZ, USA.
    +

    "The configuration is intuitive and flexible, and much easier than any -of the other iptables-based firewall programs out there. After sifting through -many other scripts, it is obvious that yours is the most well thought-out -and complete one available." -- BC, USA

    + of the other iptables-based firewall programs out there. After sifting through + many other scripts, it is obvious that yours is the most well thought-out + and complete one available." -- BC, USA

    +

    "I just installed Shorewall after weeks of messing with ipchains/iptables - and I had it up and running in under 20 minutes!" -- JL, Ohio
    -

    - "My case was almost like [the one above]. Well. instead of 'weeks' it was - 'months' for me, and I think I needed two minutes more:
    - + and I had it up and running in under 20 minutes!" -- JL, Ohio
    +

    + "My case was almost like [the one above]. Well. instead of 'weeks' it +was 'months' for me, and I think I needed two minutes more:
    +
      -
    • One to see that I had no Internet access from the firewall itself.
      • -
    • Other to see that this was the default configuration, and it was -enough to uncomment a line in /etc/shorewall/policy.
      -
      • - +
    • One to see that I had no Internet access from the firewall itself.
      • +
    • Other to see that this was the default configuration, and it was + enough to uncomment a line in /etc/shorewall/policy.
      +
      • +
    - Minutes instead of months! Congratulations and thanks for such a simple -and well documented thing for something as huge as iptables." -- JV, Spain. - + Minutes instead of months! Congratulations and thanks for such a simple + and well documented thing for something as huge as iptables." -- JV, Spain. +

    "I downloaded Shorewall 1.2.0 and installed it on Mandrake 8.1 without - any problems. Your documentation is great and I really appreciate -your network configuration info. That really helped me out alot. THANKS!!!" - -- MM.

    - + any problems. Your documentation is great and I really appreciate your + network configuration info. That really helped me out alot. THANKS!!!" + -- MM.

    +

    "[Shorewall is a] great, great project. I've used/tested may firewall - scripts but this one is till now the best." -- B.R, Netherlands -

    - + scripts but this one is till now the best." -- B.R, Netherlands +

    +

    "Never in my +12 year career as a sys admin have I witnessed someone - so relentless in developing a secure, state of the art, safe and useful - product as the Shorewall firewall package for no cost or obligation + so relentless in developing a secure, state of the art, safe and +useful product as the Shorewall firewall package for no cost or obligation involved." -- Mario Kerecki, Toronto

    - -

    "one time more to report, that your great shorewall in the latest - release 1.2.9 is working fine for me with SuSE Linux 7.3! I now -have 7 machines up and running with shorewall on several versions - -starting with 1.2.2 up to the new 1.2.9 and I never have encountered -any problems!" -- SM, Germany

    - + +

    "one time more to report, that your great shorewall in the latest release + 1.2.9 is working fine for me with SuSE Linux 7.3! I now have 7 machines +up and running with shorewall on several versions - starting with 1.2.2 +up to the new 1.2.9 and I never have encountered any problems!" -- SM, +Germany

    +

    "You have the best support of any other package I've ever used." - -- SE, US

    - + -- SE, US

    +

    "Because our company has information which has been classified by the national government as secret, our security doesn't stop by putting a fence - around our company. Information security is a hot issue. We also make use - of checkpoint firewalls, but not all of the internet servers are guarded - by checkpoint, some of them are running....Shorewall." -- Name withheld -by request, Europe

    - + around our company. Information security is a hot issue. We also make +use of checkpoint firewalls, but not all of the internet servers are guarded + by checkpoint, some of them are running....Shorewall." -- Name withheld + by request, Europe

    +

    "thanx for all your efforts you put into shorewall - this product stands - out against a lot of commercial stuff i´ve been working with in terms of - flexibillity, quality & support" -- RM, Austria

    - + out against a lot of commercial stuff i´ve been working with in terms +of flexibillity, quality & support" -- RM, Austria

    +

    "I have never seen such a complete firewall package that is so easy to - configure. I searched the Debian package system for firewall scripts and - Shorewall won hands down." -- RG, Toronto

    - + configure. I searched the Debian package system for firewall scripts and + Shorewall won hands down." -- RG, Toronto

    +

    "My respects... I've just found and installed Shorewall 1.3.3-1 and it - is a wonderful piece of software. I've just sent out an email to about + is a wonderful piece of software. I've just sent out an email to about 30 people recommending it. :-)
    - While I had previously taken the time (maybe 40 hours) to really understand - ipchains, then spent at least an hour per server customizing and carefully - scrutinizing firewall rules, I've got shorewall running on my home firewall, - with rulesets and policies that I know make sense, in under 20 minutes." - -- RP, Guatamala
    -
    -  

    - -

    Updated 3/18/2003 - - Tom Eastep -

    - + While I had previously taken the time (maybe 40 hours) to really understand + ipchains, then spent at least an hour per server customizing and carefully + scrutinizing firewall rules, I've got shorewall running on my home firewall, + with rulesets and policies that I know make sense, in under 20 minutes." + -- RP, Guatamala
    +
    +  

    + +

    Updated 7/1/2003 + - Tom Eastep +

    +

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

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

    +

    +


    diff --git a/STABLE/documentation/samba.htm b/STABLE/documentation/samba.htm index cd6964bda..f4b8ba092 100644 --- a/STABLE/documentation/samba.htm +++ b/STABLE/documentation/samba.htm @@ -1,98 +1,114 @@ + - - - - - -Samba + + + + + + + + + Samba - - - - - - - + + +
    -

    Samba

    -
    + + + + + +
    +

    Samba

    +
    -

    If you wish to run Samba on your firewall and access shares between the + +

    If you wish to run Samba on your firewall and access shares between the firewall and local hosts, you need the following rules:

    +

    /etc/shorewall/rules:

    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST - PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACCEPTfwlocudp137:139  
    ACCEPTfwloctcp137,139  
    ACCEPTfwlocudp1024:137 
    ACCEPTlocfwudp137:139  
    ACCEPTlocfwtcp137,139  
    ACCEPTlocfwudp1024:137 
    -
    -

    Last modified 5/29/2002 - Tom -Eastep

    -Copyright © 2002 Thomas M. Eastep. \ No newline at end of file + +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTfwlocudp137:139  
    ACCEPTfwloctcp137,139  
    ACCEPTfwlocudp1024:137 
    ACCEPTlocfwudp137:139  
    ACCEPTlocfwtcp137,139  
    ACCEPTlocfwudp1024:137 
    +
    + +

    Last modified 5/29/2002 - Tom Eastep

    +

    Copyright +© 2002 Thomas M. Eastep.

    +
    + + diff --git a/STABLE/documentation/seattlefirewall_index.htm b/STABLE/documentation/seattlefirewall_index.htm index 9dcad3225..2c49a54b4 100644 --- a/STABLE/documentation/seattlefirewall_index.htm +++ b/STABLE/documentation/seattlefirewall_index.htm @@ -2,67 +2,94 @@ - + + Shoreline Firewall (Shorewall) 1.4 - + + - - + bgcolor="#3366ff"> - + - + - - + - + - - - + +
    + + + + + +
    - + - -

    Shorewall 1.4 "iptables made easy"

    -     		+ + + +
    + + + + (Shorewall Logo) +
    +     		+ +

    (Shorewall Logo) -

    -
    -
    - -
    -
    + + +
    +
    + +
    +
    + - + - + - - - + +
    + - + - - + + +
    + + +
    - + +
    +
    +

    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 @@ -70,34 +97,40 @@ - + + +

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

    + 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, 2003 Thomas M. Eastep

    @@ -106,360 +139,481 @@ the GNU General Public License - + + + +

    This is the Shorewall 1.4 Web Site

    + The information on this site applies only to 1.4.x releases of Shorewall. + For older versions:
    + +
      +
    • The 1.3 site is here.
      • +
    • The 1.2 site is here.
      +
      • + +
    + +

    Getting Started with Shorewall

    + New to Shorewall? Start by selecting + the QuickStart Guide + that most closely match your environment and follow the +step by step instructions.
    + + +

    Looking for Information?

    + The Documentation + Index is a good place to start as is the Quick Search to your right. +

    Running Shorewall on Mandrake with a two-interface setup?

    - If so, almost NOTHING on this site will apply directly - to your setup. If you want to use the documentation that you find here, - it is best if you uninstall what you have and install a setup that -matches the documentation on this site. See the Two-interface QuickStart Guide for details.
    - - -

    Getting Started with Shorewall

    - New to Shorewall? Start by selecting the QuickStart Guide that most closely - match your environment and follow the step by step instructions.
    - - - + If so, the documentation on this site + will not apply directly to your setup. If you want to use the + documentation that you find here, you will want to consider uninstalling + what you have and installing a setup that matches the documentation + on this site. See the Two-interface + QuickStart Guide for details.
    + +

    News

    - -

    6/17/2003 - Shorewall-1.4.5 (New) -

    - -

    Problems Corrected:
    -

    - + + +
      -
    1. The command "shorewall debug try <directory>" now correctly -traces the attempt.
      2. -
    2. The INCLUDE directive now works properly in the zones file; previously, -INCLUDE in that file was ignored.
      3. -
    3. /etc/shorewall/routestopped records with an empty second column -are no longer ignored.
      -
      4. -
    - -

    New Features:
    -

    - -
      -
    1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may -now contain a list of addresses. If the list begins with "!' then the rule -will take effect only if the original destination address in the connection -request does not match any of the addresses listed.
      2. -
    -

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 - (New) -

    - -

    The firewall at shorewall.net has been upgraded to the 2.4.21 kernel -and iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems - have been encountered with this set of software. The Shorewall version is - 1.4.4b plus the accumulated changes for 1.4.5.
    -

    - -

    6/8/2003 - Updated Samples

    - -

    Thanks to Francesca Smith, the samples have been updated to Shorewall - version 1.4.4.

    - -

    5/29/2003 - Shorewall-1.4.4b

    - -

    Groan -- This version corrects a problem whereby the --log-level - was not being set when logging via syslog. The most commonly reported symptom - was that Shorewall messages were being written to the console even though - console logging was correctly configured per FAQ - 16.
    -

    - -

    5/27/2003 - Shorewall-1.4.4a

    - The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed - out that the code in 1.4.4 restricts the length of short zone names to - 4 characters. I've produced version 1.4.4a that restores the previous -5-character limit by conditionally omitting the log rule number when -the LOGFORMAT doesn't contain '%d'. - -

    5/23/2003 - Shorewall-1.4.4 -

    - I apologize for the rapid-fire releases but since there is a potential - configuration change required to go from 1.4.3a to 1.4.4, I decided to - make it a full release rather than just a bug-fix release.
    -
    - Problems corrected:
    - -
    None.
    -
    - New Features:
    -     - -
      -
    1. A REDIRECT- rule target has been added. This target -behaves for REDIRECT in the same way as DNAT- does for DNAT in that the -Netfilter nat table REDIRECT rule is added but not the companion filter -table ACCEPT rule.
      -
      -
      2. -
    2. The LOGMARKER variable has been renamed LOGFORMAT and - has been changed to a 'printf' formatting template which accepts three - arguments (the chain name, logging rule number and the disposition). -To use LOGFORMAT with fireparse (http://www.fireparse.com), - set it as:
      -
      - LOGFORMAT="fp=%s:%d a=%s "
      -
      - CAUTION: /sbin/shorewall uses the leading part of the - LOGFORMAT string (up to but not including the first '%') to find log -messages in the 'show log', 'status' and 'hits' commands. This part should -not be omitted (the LOGFORMAT should not begin with "%") and the leading -part should be sufficiently unique for /sbin/shorewall to identify Shorewall - messages.
      -
      -
      3. -
    3. When logging is specified on a DNAT[-] or REDIRECT[-] - rule, the logging now takes place in the nat table rather than in the -filter table. This way, only those connections that actually undergo DNAT -or redirection will be logged.
      -
      4. - -
    - -

    5/20/2003 - Shorewall-1.4.3a
    -

    - This version primarily corrects the documentation included in -the .tgz and in the .rpm. In addition:
    - - -
      -
    1. (This change is in 1.4.3 but is not documented) If -you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will -return reject replies as follows:
      - a) tcp - RST
      - b) udp - ICMP port unreachable
      - c) icmp - ICMP host unreachable
      - d) Otherwise - ICMP host prohibited
      - If you are running earlier software, Shorewall will follow it's - traditional convention:
      - a) tcp - RST
      - b) Otherwise - ICMP port unreachable
      2. -
    2. UDP port 135 is now silently dropped in the common.def - chain. Remember that this chain is traversed just before a DROP or REJECT - policy is enforced.
      -
      3. - - -
    - - -

    5/18/2003 - Shorewall 1.4.3
    -

    - Problems Corrected:
    -     - -
      -
    1. There were several cases where Shorewall would fail - to remove a temporary directory from /tmp. These cases have been corrected.
      2. -
    2. The rules for allowing all traffic via the loopback - interface have been moved to before the rule that drops status=INVALID - packets. This insures that all loopback traffic is allowed even if -Netfilter connection tracking is confused.
      3. - - -
    - New Features:
    -     - -
      -
    1. IPV6-IPV4 (6to4) tunnels are - now supported in the /etc/shorewall/tunnels file.
      2. -
    2. You may now change the leading portion of the --log-prefix - used by Shorewall using the LOGMARKER variable in shorewall.conf. By -default, "Shorewall:" is used.
      -
      3. - - -
    - - -

    5/10/2003 - Shorewall Mirror in Asia
    -

    - Ed Greshko has established a mirror in Taiwan -- Thanks -Ed! - -

    5/8/2003 - Shorewall Mirror in Chile

    - - -

    Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
    -

    - - -

    4/26/2003 - lists.shorewall.net Downtime

    - -

    The list server will be down this morning for upgrade to RH9.0.
    -

    + - -

    4/21/2003 - Samples updated for Shorewall version 1.4.2 -

    + +

    7/20/2003 - Shorewall-1.4.6 (New) +
    +

    + +
    + +

    Problems Corrected:
    +

    + + +
      +
    1. A problem seen on RH7.3 systems where Shorewall encountered + start errors when started using the "service" mechanism has been worked + around.
      +
      +
      2. +
    2. Where a list of IP addresses appears in the DEST column + of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules +in the nat table (one for each element in the list). Shorewall now correctly + creates a single DNAT rule with multiple "--to-destination" clauses.
      +
      +
      3. +
    3. Corrected a problem in Beta 1 where DNS names containing + a "-" were mis-handled when they appeared in the DEST column of a rule.
      +
      +
      4. +
    4. A number of problems with rule parsing have been corrected. + Corrections involve the handling of "z1!z2" in the SOURCE column as well + as lists in the ORIGINAL DESTINATION column.
      +
      +
      5. +
    5. The message "Adding rules for DHCP" is now suppressed if there +are no DHCP rules to add.
      +
      6. + +
    + + +

    Migration Issues:
    +

    + +
      +
    1. In earlier versions, an undocumented feature allowed +entries in the host file as follows:
      +
      +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 + to allow entries of the following format:
      +
      +     z   eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      2. +
    2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options + have been removed from /etc/shorewall/shorewall.conf. These capabilities + are now automatically detected by Shorewall (see below).
      +
      3. + +
    + +

    New Features:
    +

    + + +
      +
    1. A 'newnotsyn' interface option has been added. This +option may be specified in /etc/shorewall/interfaces and overrides the +setting NEWNOTSYN=No for packets arriving on the associated interface.
      +
      +
      2. +
    2. The means for specifying a range of IP addresses in +/etc/shorewall/masq to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes +is enabled for address ranges.
      +
      +
      3. +
    3. Shorewall can now add IP addresses to subnets other +than the first one on an interface.
      +
      +
      4. +
    4. DNAT[-] rules may now be used to load balance (round-robin) + over a set of servers. Servers may be specified in a range of addresses + given as <first address>-<last address>.
      +
      + Example:
      +
      +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +
      +
      5. +
    5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration + options have been removed and have been replaced by code that detects + whether these capabilities are present in the current kernel. The output + of the start, restart and check commands have been enhanced to report the + outcome:
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      + Verifying Configuration...
      +
      +
      6. +
    6. Support for the Connection Tracking Match Extension +has been added. This extension is available in recent kernel/iptables +releases and allows for rules which match against elements in netfilter's +connection tracking table. Shorewall automatically detects the availability +of this extension and reports its availability in the output of the start, +restart and check commands.
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      +    Connection Tracking Match: Available
      + Verifying Configuration...
      +
      + If this extension is available, the ruleset generated by Shorewall + is changed in the following ways:
      7. + + +
        +
      • To handle 'norfc1918' filtering, Shorewall will not + create chains in the mangle table but will rather do all 'norfc1918' +filtering in the filter table (rfc1918 chain).
        • +
      • Recall that Shorewall DNAT rules generate two netfilter + rules; one in the nat table and one in the filter table. If the Connection + Tracking Match Extension is available, the rule in the filter table is + extended to check that the original destination address was the same as + specified (or defaulted to) in the DNAT rule.
        +
        +
        • + + +
      +
    7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      +
      +
      8. +
    8. An 'ipcalc' command has been added to /sbin/shorewall.
      +
      +       ipcalc [ <address> <netmask> | <address>/<vlsm> + ]
      +
      + Examples:
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      + Warning:
      +
      + If your shell only supports 32-bit signed arithmatic (ash or dash), + then the ipcalc command produces incorrect information for IP addresses + 128.0.0.0-1 and for /1 networks. Bash should produce correct information + for all valid IP addresses.
      +
      +
      9. +
    9. An 'iprange' command has been added to /sbin/shorewall. +
      +
      +       iprange <address>-<address>
      +
      + This command decomposes a range of IP addressses into a list of +network and host addresses. The command can be useful if you need to construct + an efficient set of rules that accept connections from a range of network + addresses.
      +
      + Note: If your shell only supports 32-bit signed arithmetic (ash +or dash) then the range may not span 128.0.0.0.
      +
      + Example:
      +
      +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      +       192.168.1.4/30
      +       192.168.1.8/29
      +       192.168.1.16/28
      +       192.168.1.32/27
      +       192.168.1.64/26
      +       192.168.1.128/25
      +       192.168.2.0/23
      +       192.168.4.0/22
      +       192.168.8.0/22
      +       192.168.12.0/29
      +       192.168.12.8/31
      +       [root@gateway root]#
      +
      +
      10. +
    10. A list of host/net addresses is now allowed in an entry + in /etc/shorewall/hosts.
      +
      + Example:
      +
      +     foo    eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      11. +
    11. The "shorewall check" command now includes the chain name when +printing the applicable policy for each pair of zones.
      + 
      +    Example:
      + 
      +        Policy for dmz to net is REJECT using chain all2all
      + 
      +This means that the policy for connections from the dmz to the internet is +REJECT and the applicable entry in the /etc/shorewall/policy was the all->all +policy.
      +
      +
      12. +
    12. Support for the 2.6 Kernel series has been added.
      +
      13. + +
    + +

    7/15/2003 - New Mirror in Brazil (New) +
    +

    + Thanks to the folks at securityopensource.org.br, there is now a Shorewall + mirror in Brazil. +

    6/17/2003 - Shorewall-1.4.5

    + + +

    Problems Corrected:
    +

    + + +
      +
    1. The command "shorewall debug try <directory>" + now correctly traces the attempt.
      2. +
    2. The INCLUDE directive now works properly in the + zones file; previously, INCLUDE in that file was ignored.
      3. +
    3. /etc/shorewall/routestopped records with an empty + second column are no longer ignored.
      +
      4. -

      Thanks to Francesca Smith, the sample configurations are now upgraded - to Shorewall version 1.4.2.

      +
    + +

    New Features:
    +

    + + +
      +
    1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] + rule may now contain a list of addresses. If the list begins with +"!' then the rule will take effect only if the original destination +address in the connection request does not match any of the addresses +listed.
      2. -

      4/12/2002 - Greater Seattle Linux Users Group Presentation -

      +
    + + +

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 +

    + + +

    The firewall at shorewall.net has been upgraded to the 2.4.21 kernel + and iptables 1.2.8 (using the "official" RPM from netfilter.org). +No problems have been encountered with this set of software. The Shorewall + version is 1.4.4b plus the accumulated changes for 1.4.5.
    +

    + + +

    6/8/2003 - Updated Samples

    + + +

    Thanks to Francesca Smith, the samples have been updated to Shorewall + version 1.4.4.

    + + +

    + + +
      - - -
      This morning, I gave a - Shorewall presentation to GSLUG. The presentation - is in HTML format but was generated from Microsoft PowerPoint and - is best viewed using Internet Explorer (although Konqueror also seems - to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor - Netscape work well to view the presentation.
      -
      + +
    - - - -
    - -
      - - - - - -
    -
    - - - - - +

    More News

    - + + +

    (Leaf Logo) - 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.14 and Kernel-2.4.20. You - can find their work at: http://leaf.sourceforge.net/devel/jnilo
    +     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.4.2 and Kernel-2.4.20. + You can find their work at: + http://leaf.sourceforge.net/devel/jnilo
    -

    +

    - Congratulations to Jacques and Eric on the recent release - of Bering 1.2!!!
    + Congratulations to Jacques and Eric +on the recent release of Bering 1.2!!!
    - + + +

    Donations

    -     		+ + + + +

    - Note:     Search is unavailable Daily 0200-0330 GMT.
    - + - + + +

    Quick Search
    - -

    -
    + +

    + + + - + + +

    Extended Search

    -
    -
    -
    +
    -
    - + + + + bgcolor="#3366ff"> - + - + - + - + - - + + +
    + - + + +

    (Starlight Logo) -

    +

    - + + +


    - 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 6/17/2003 - Tom Eastep -
    + + +

    Updated 7/19/2003 - Tom Eastep +

    diff --git a/STABLE/documentation/shoreline.htm b/STABLE/documentation/shoreline.htm index a23d64d03..c2337d3ff 100644 --- a/STABLE/documentation/shoreline.htm +++ b/STABLE/documentation/shoreline.htm @@ -1,135 +1,138 @@ - + About the Shorewall Author - + + - + - + - + - - - + + - - - + + + +
    - + bgcolor="#3366ff" height="90"> +
    +

    Tom Eastep

    -
    - +

    Tom - June 2003 -

    - + alt="Aging Geek - June 2003" width="320" height="240"> +

    +

    Tom -- June 2003
    -
    -

    - +
    +

    + - +

    I am currently a member of the design team for the next-generation operating - system from the NonStop Enterprise Division of HP.

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

    - +

    Our current home network consists of:

    - +
      -
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, -40GB & 20GB IDE HDs and LNE100TX (Tulip) NIC - My personal -Windows system. Serves as a PPTP server for Road Warrior access. Dual -boots Mandrake 9.0.
      • -
    • Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, -LNE100TX(Tulip) NIC - My personal Linux System which runs Samba. - 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 and Mailman), HTTP (Apache), -FTP (Pure_ftpd), DNS server (Bind 9).
      • -
    • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - - 3 LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall - 1.4.4c, a DHCP server and Samba configured as a WINS server..
      • -
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 - NIC - My wife's personal system.
      • -
    • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB - HD, built-in EEPRO100, EEPRO100 in expansion base - My work system.
      • -
    • XP 2200 Laptop, WinXP SP1, 512MB RAM, 40GB HD, built-in NIC and - LinkSys WET11 - Our Laptop.
      -
      • - +
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, + 40GB & 20GB IDE HDs and LNE100TX (Tulip) NIC - My personal + Windows system. Serves as a PPTP server for Road Warrior access. Dual + boots Mandrake 9.0.
      • +
    • Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, + LNE100TX(Tulip) NIC - My personal Linux System which runs +Samba. 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 and Mailman), HTTP (Apache), + FTP (Pure_ftpd), DNS server (Bind 9).
      • +
    • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI + HD - 3 LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall + 1.4.6Beta1, a DHCP server and Samba configured as a WINS server..
      • +
    • Duron 750, Win ME, 192MB RAM, 20GB HD, +RTL8139 NIC - My wife's personal system.
      • +
    • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB + HD, built-in EEPRO100, EEPRO100 in expansion base - My work system.
      • +
    • XP 2200 Laptop, WinXP SP1, 512MB RAM, 40GB HD, built-in NIC +and LinkSys WET11 - Our Laptop.
      +
      • +
    - +

    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.

    - +

    - - - - Powered by Mandrake - Protected by Shorewall - (Opera Logo) -     -

    - -

    Last updated 6/15/2003 -

    + +

    Last updated 7/14/2003 - Tom Eastep

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

    diff --git a/STABLE/documentation/shorewall_extension_scripts.htm b/STABLE/documentation/shorewall_extension_scripts.htm index 9b9fbe0c5..a18b8b96a 100644 --- a/STABLE/documentation/shorewall_extension_scripts.htm +++ b/STABLE/documentation/shorewall_extension_scripts.htm @@ -1,126 +1,118 @@ - + - + - + - + Shorewall Extension Scripts - - + - - - - - + + - - - - - + + + +
    - + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    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:

    - + +

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

    + +

    Caution:
    +

    + +
      +
    1. Be sure that you actually need to use an +extension script to do what you want. Shorewall has a wide range of features +that cover most requirements.
      2. +
    2. DO NOT SIMPLY COPY RULES THAT YOU FIND ON +THE NET INTO AN EXTENSION SCRIPT AND EXPECT THEM TO WORK AND TO NOT BREAK + SHOREWALL. TO USE SHOREWALL EXTENSION SCRIPTS YOU MUST KNOW WHAT YOU ARE +DOING WITH RESPECT TO iptables/Netfilter
      3. + +
    + +

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

    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.

    - - - - -

    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

    - - - - + +

    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.

    + +

    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:

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

    - - - -

    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.

    - - - -

    Last updated 2/18/2003 - + +

    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.

    + +

    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
    +

    + +

    + +

    Last updated 6/30/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 -Thomas M. Eastep

    + +

    Copyright 2002, 2003 + Thomas M. Eastep

    +
    +

    +

    diff --git a/STABLE/documentation/shorewall_features.htm b/STABLE/documentation/shorewall_features.htm index e025fa940..c043b43f7 100644 --- a/STABLE/documentation/shorewall_features.htm +++ b/STABLE/documentation/shorewall_features.htm @@ -1,117 +1,118 @@ - + - + - + - + Shorewall Features - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Shorewall Features

    -
    - + - +

    Last updated 2/5/2003 - Tom Eastep

    - +

    Copyright © 2001-2003 Thomas M. Eastep.
    -

    +

    +


    diff --git a/STABLE/documentation/shorewall_firewall_structure.htm b/STABLE/documentation/shorewall_firewall_structure.htm index b27c3ee0b..d738a23dc 100644 --- a/STABLE/documentation/shorewall_firewall_structure.htm +++ b/STABLE/documentation/shorewall_firewall_structure.htm @@ -1,195 +1,197 @@ - + - + - + - + Shorewall Firewall Structure - + - - - - - - + id="AutoNumber1" bgcolor="#3366ff" height="90"> + + + + + +
    -

    Firewall Structure

    -
    +

    Firewall Structure (Under +Construction)

    +
    - +

    Shorewall views the network in which it is running as a set of zones. Shorewall itself defines exactly one zone called "fw" which - refers to the firewall system itself . The /etc/shorewall/zones file is - used to define additional zones and the example file provided with Shorewall - defines the zones:

    - + refers to the firewall system itself . The /etc/shorewall/zones file +is used to define additional zones and the example file provided with +Shorewall defines the zones:

    +
      -
    1. net -- the (untrusted) internet.
      2. -
    2. dmz - systems that must be accessible from the internet - and from the local network.  These systems cannot be trusted completely +
    3. net -- the (untrusted) internet.
      4. +
    4. dmz - systems that must be accessible from the internet + and from the local network.  These systems cannot be trusted completely since their servers may have been compromised through a security exploit.
      5. -
    5. loc - systems in your local network(s). These systems - must be protected from the internet and from the DMZ and in some cases, - from each other.
      6. - +
    6. loc - systems in your local network(s). These systems + must be protected from the internet and from the DMZ and in some +cases, from each other.
      7. +
    - +

    Note: You can specify the name of the firewall zone. For ease of description in this documentation, it is assumed that the firewall zone is named "fw".

    - +

    It can't be stressed enough that with the exception of the firewall zone, - Shorewall itself attaches no meaning to zone names. Zone names are simply - labels used to refer to a collection of network hosts.

    - + Shorewall itself attaches no meaning to zone names. Zone names are simply + labels used to refer to a collection of network hosts.

    +

    While zones are normally disjoint (no two zones have a host in common), - there are cases where nested or overlapping zone definitions are appropriate.

    - + there are cases where nested or overlapping zone definitions are appropriate.

    +

    Netfilter has the concept of tables and chains. For the purpose of this document, we will consider Netfilter to have three tables:

    - +
      -
    1. Filter table -- this is the main table for packet filtering and can -be displayed with the command "shorewall show".
      2. -
    2. Nat table -- used for all forms of Network Address Translation (NAT); -SNAT, DNAT and MASQUERADE.
      3. -
    3. Mangle table -- used to modify fields in the packet header.
      -
      4. - +
    4. Filter table -- this is the main table for packet filtering and +can be displayed with the command "shorewall show".
      5. +
    5. Nat table -- used for all forms of Network Address Translation (NAT); + SNAT, DNAT and MASQUERADE.
      6. +
    6. Mangle table -- used to modify fields in the packet header.
      +
      7. +
    - +

    Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT, -FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables -as shown in this table.
    -

    - -
    + FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables + as shown in this table.
    +

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    CHAIN
    -     		Filter
    -     		Nat
    -     		Mangle
    -
    PREROUTING
    -
    -     		X
    -     		X
    -
    INPUT
    -     		X
    -
    -     		X
    -
    OUTPUT
    -     		X
    -     		X
    -     		X
    -
    FORWARD
    -     		X
    -
    -     		X
    -
    POSTROUTING
    -
    -     		X
    -     		X
    -
    CHAIN
    +     		Filter
    +     		Nat
    +     		Mangle
    +
    PREROUTING
    +
    +     		X
    +     		X
    +
    INPUT
    +     		X
    +
    +     		X
    +
    OUTPUT
    +     		X
    +     		X
    +     		X
    +
    FORWARD
    +     		X
    +
    +     		X
    +
    POSTROUTING
    +
    +     		X
    +     		X
    +
    -
    - +
    +

    Shorewall doesn't create rules in all of the builtin chains. In the large -diagram below are boxes such as  shown below.  This box represents in INPUT -chain and shows that packets first flow through the INPUT chain in the Mangle -table followed by the INPUT chain in the Filter table. The parentheses around -"Mangle" indicate that while the packets will flow through the INPUT chain -in the Mangle table, Shorewall does not create any rules in that chain.
    -

    - + diagram below are boxes such as  shown below.  This box represents in INPUT + chain and shows that packets first flow through the INPUT chain in the Mangle + table followed by the INPUT chain in the Filter table. The parentheses around + "Mangle" indicate that while the packets will flow through the INPUT chain + in the Mangle table, Shorewall does not create any rules in that chain.
    +

    +
    (Box Legend) -
    -
    - +
    + +

    - +

    Here is a picture of how packets traverse the various chains and tables - in Netfilter. In that diagram, "Local Process" refers to a process running - on the Firewall itself (in the 'fw' zone).

    - + in Netfilter. In that diagram, "Local Process" refers to a process running + on the Firewall itself (in the 'fw' zone).

    +
    Netfilter Flow Diagram -
    - + +


    -
    - In the text that follows, the paragraph numbers correspond to the box number -in the diagram above.
    -

    - +
    + In the text that follows, the paragraph numbers correspond to the box +number in the diagram above.
    +

    +
      -
    1. Packets entering the firewall first pass through the mangle table's - PREROUTING chain (you can see the mangle table by typing "shorewall show - mangle"). If the packet entered through an interface that has the norfc1918 - option, then the packet is sent down the man1918 chain which will - drop the packet if its destination IP address is reserved (as specified -in the /etc/shorewall/rfc1918 file). Next the packet passes through the -pretos chain to set its TOS field as specified in the /etc/shorewall/tos -file. Finally, if traffic control/shaping is being used, the packet is sent -through the tcpre chain to be marked for later use in policy routing -or traffic control.
      -
      - Next, if the packet isn't part of an established connection, it passes - through the nat table's PREROUTING chain (you can see the nat table - by typing "shorewall show nat"). If you are doing both static nat and -port forwarding, the order in which chains are traversed is dependent on +
    2. Packets entering the firewall first pass through the mangle table's + PREROUTING chain (you can see the mangle table by typing "shorewall show + mangle"). If the packet entered through an interface that has the norfc1918 + option and if iptables/netfilter doesn't support the connection tracking +match extension, then the packet is sent down the man1918 chain which +will drop the packet if its destination IP address is reserved (as specified + in the /etc/shorewall/rfc1918 file). Next the packet passes through the + pretos chain to set its TOS field as specified in the /etc/shorewall/tos + file. Finally, if traffic control/shaping is being used, the packet is +sent through the tcpre chain to be marked for later use in policy +routing or traffic control.
      +
      + Next, if the packet isn't part of an established connection, it passes + through the nat table's PREROUTING chain (you can see the nat table + by typing "shorewall show nat"). If you are doing both static nat and + port forwarding, the order in which chains are traversed is dependent on the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is on then packets will ender a chain called interface_in where interface is the name of the interface on which the packet entered. -Here it's destination IP is compared to each of the EXTERNAL IP + Here it's destination IP is compared to each of the EXTERNAL IP addresses from /etc/shorewall/nat that correspond to this interface; if there is a match, DNAT is applied and the packet header is modified to the IP in the INTERNAL column of the nat file record. If the destination @@ -197,137 +199,133 @@ address doesn't match any of the rules in the interface_in chain then the packet enters a chain called sourcezone_dnat where sourcezone is the source zone of the packet. There it is compared for a match against each of the DNAT records in the rules file that specify - sourcezone as the source zone. If a match is found, the destination -IP address (and possibly the destination port) is modified based on the -rule matched. If NAT_BEFORE_RULES is off, then the order of traversal of -the interface_in and sourcezone_dnat is reversed.
      + sourcezone as the source zone. If a match is found, the +destination IP address (and possibly the destination port) is modified based +on the rule matched. If NAT_BEFORE_RULES is off, then the order of traversal +of the interface_in and sourcezone_dnat is +reversed.
      +
      +
      3. +
    3. Depending on whether the packet is destined for the firewall itself + or for another system, it follows either the left or the right path. Traffic + going to the firewall goes through chain called INPUT in the mangle table. + Shorewall doesn't add any rules to that chain.
      +
      +
      4. +
    4. Traffic that is to be forwarded to another host goes through the chains +called FORWARD in the mangle table. If MARK_IN_FORWARD=Yes in shorewall.conf, +all rules in /etc/shorewall/tcrules that do not specify Prerouting (:P) are +processed in a chain called

      5. -
    5. Depending on whether the packet is destined for the firewall itself -or for another system, it follows either the left or the right path. Traffic -going to the firewall goes through chains called INPUT in the mangle table. -Shorewall doesn't add any rules to that chain. Traffic next passes the the -INPUT chain in the filter table where it is broken out based on the interface -on which the packet arrived; packets from interface interface are routed -to chain interface_in. For example, packets arriving through -eth0 are passed to the chain eth0_in.
        6. -
      1. The first rule in interface_in jumps to the chain -named dynamic which matches the source IP in the packet against all -of the addresses that have been blacklisted using dynamic blacklisting.
        2. -
      2. If the the interface has the norfc1918 option then the packet -is sent down the rfc1918 which checks the source address against those -listed in /etc/shorewall/rfc1918 and treats the packet according to the first -match in that file (if any).
        3. -
      3. If the interface has the  dhcp option, UDP packets to ports -67 and 68 are accepted.
        4. -

      4. -
        5. - +
      -
    6. Traffic is next sent to an input chain in the mail Netfilter - table (called 'filter'). If the traffic is destined for the firewall itself, - the name of the input chain is formed by appending "_in" to the interface - name. So traffic on eth0 destined for the firewall will enter a chain called - eth0_in. The input chain for traffic that will be routed to -another system is formed by appending "_fwd" to the interface name. So traffic - from eth1 that is going to be forwarded enters a chain called eth1_fwd. - Interfaces described with the wild-card character ("+") in /etc/shorewall/interfaces, - share input chains. if ppp+ appears in /etc/shorewall/interfaces -then all PPP interfaces (ppp0, ppp1, ...) will share the input chains ppp_in - and ppp_fwd. In other words, "+" is deleted from the name before -forming the input chain names.
      7. - +
    7. Traffic is next sent to an interface chain in the main Netfilter + table (called 'filter'). If the traffic is destined for the firewall +itself, the name of the interface chain is formed by appending "_in" to + the interface name. So traffic on eth0 destined for the firewall will +enter a chain called eth0_in. The interface chain for traffic +that will be routed to another system is formed by appending "_fwd" to +the interface name. So traffic from eth1 that is going to be forwarded +enters a chain called eth1_fwd. Interfaces described with the wild-card +character ("+") in /etc/shorewall/interfaces, share input chains. if ppp+ + appears in /etc/shorewall/interfaces then all PPP interfaces (ppp0, +ppp1, ...) will share the interface chains ppp_in and ppp_fwd. +In other words, "+" is deleted from the name before forming the input chain +names.
      +
      + While the use of interfacechains may seem wasteful in simple environments, + in complex setups it substantially reduces the number of rules that each + packet must traverse. 
      8. +
    - -

    While the use of input chains may seem wasteful in simple environments, - in complex setups it substantially reduces the number of rules that each - packet must traverse. 

    - +

    Traffic directed from a zone to the firewall itself is sent through a chain named <zone name>2fw. For example, traffic inbound from - the internet and addressed to the firewall is sent through a chain named - net2fw. Similarly, traffic originating in the firewall and being sent to - a host in a given zone is sent through a chain named fw2<zone name>. - For example, traffic originating in the firewall and destined - for a host in the local network is sent through a chain named fw2loc. -  

    - + the internet and addressed to the firewall is sent through a chain named + net2fw. Similarly, traffic originating in the firewall and being sent +to a host in a given zone is sent through a chain named fw2<zone +name>. For example, traffic originating in the firewall and +destined for a host in the local network is sent through a chain named +fw2loc.  

    +

    Traffic being forwarded between two zones (or from one interface to a zone to another interface to that zone) is sent through a chain named - <source zone>2 <destination zone>. So for example, - traffic originating in a local system and destined for a remote web server - is sent through chain loc2net. This chain is referred to as -the canonical chain from <source zone> to <destination - zone>. Any destination NAT will have occurred before the packet - traverses one of these chains so rules in /etc/shorewall/rules should be - expressed in terms of the destination system's real IP address as opposed - to its apparent external address. Similarly, source NAT will occur after - the packet has traversed the appropriate forwarding chain so the rules - again will be expressed using the source system's real IP address.

    - + <source zone>2 <destination zone>. So for example, + traffic originating in a local system and destined for a remote web server + is sent through chain loc2net. This chain is referred to +as the canonical chain from <source zone> to <destination + zone>. Any destination NAT will have occurred before the packet + traverses one of these chains so rules in /etc/shorewall/rules should +be expressed in terms of the destination system's real IP address as opposed + to its apparent external address. Similarly, source NAT will occur after + the packet has traversed the appropriate forwarding chain so the rules + again will be expressed using the source system's real IP address.

    +

    For each record in the /etc/shorewall/policy file, a chain is created. - Policies in that file are expressed in terms of a source zone and destination - zone where these zones may be a zone defined in /etc/shorewall/zones, + Policies in that file are expressed in terms of a source zone and destination + zone where these zones may be a zone defined in /etc/shorewall/zones, "fw" or "all". Policies specifying the pseudo-zone "all" matches all defined - zones and "fw". These chains are referred to as Policy Chains. Notice - that for an ordered pair of zones (za,zb), the canonical chain (za2zb) -may also be the policy chain for the pair or the policy chain may be a -different chain (za2all, for example). Packets from one zone to another -will traverse chains as follows:

    - + zones and "fw". These chains are referred to as Policy Chains. Notice + that for an ordered pair of zones (za,zb), the canonical chain (za2zb) + may also be the policy chain for the pair or the policy chain may be +a different chain (za2all, for example). Packets from one zone to another + will traverse chains as follows:

    +
      -
    1. If the canonical chain exists, packets first traverse that - chain.
      2. -
    2. If the canonical chain and policy chain are different and - the packet does not match a rule in the canonical chain, it then is sent - to the policy chain.
      3. -
    3. If the canonical chain does not exist, packets are sent -immediately to the policy chain.
      4. - +
    4. If the canonical chain exists, packets first traverse +that chain.
      5. +
    5. If the canonical chain and policy chain are different +and the packet does not match a rule in the canonical chain, it then +is sent to the policy chain.
      6. +
    6. If the canonical chain does not exist, packets are sent + immediately to the policy chain.
      7. +
    - +

    The canonical chain from zone za to zone zb will be created only if there are exception rules defined in /etc/shorewall/rules for packets going from za to zb.

    - +

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

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

    +
      -
    1. Identify the client's zone.
      2. -
    2. Identify the server's 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 client's zone.
      6. +
    6. Identify the server's 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 between zone - A and the firewall and are also allowed between the firewall and zone + A and the firewall and are also allowed between the firewall and zone B DOES NOT mean that these connections are allowed between zone A and 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 and then establishes its own separate connection from the +firewall to zone B.

    +

    If you adopt the default policy of ACCEPT from the local zone to the - internet zone and you are having problems connecting from a local client - to an internet server, adding a rule won't - help (see point 3 above).

    - + internet zone and you are having problems connecting from a local client + to an internet server, adding a rule won't + help (see point 3 above).

    +

    Last modified 5/22/2003 - Tom Eastep

    - +

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

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

    +
    +
    +


    diff --git a/STABLE/documentation/shorewall_logging.html b/STABLE/documentation/shorewall_logging.html index 4a2fb50b2..747ea76d1 100755 --- a/STABLE/documentation/shorewall_logging.html +++ b/STABLE/documentation/shorewall_logging.html @@ -2,155 +2,151 @@ Shorewall Logging - + - + - + - - - + + - - - + + + +
    - - + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Logging

    -
    -
    - By default, Shorewall directs NetFilter to log using syslog (8). Syslog - classifies log messages by a facility and a priority (using +
    + 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 +
    + 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. +
    + 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 + + 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       +
    + Valid levels are:
    +
    +        7       debug
    -        6       +        6       info
    -        5       +        5       notice
    -        4       +        4       warning
    -        3       +        3       err
    -        2       +        2       crit
    -        1       +        1       alert
    -        0       +        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 +
    + 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 +
    + 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:
    - + There are a couple of limitations to syslogd-based logging:
    +
      -
    1. 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) +
    2. 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).
      3. -
    3. All kernel.info messages will go to that destination and not just +
    4. All kernel.info messages will go to that destination and not just those from NetFilter.
      -
      5. - + +
    - 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.
    -
    - Note: The ULOG logging mechanism is completely separate from -syslog. Once you switch to ULOG, the settings in /etc/syslog.conf have absolutely -no effect on your Shorewall logging (except for Shorewall status messages + 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.
    +
    + Note: The ULOG logging mechanism is completely separate from +syslog. Once you switch to ULOG, the settings in /etc/syslog.conf have absolutely +no effect on your Shorewall logging (except for Shorewall status messages which still go to syslog).
    -
    -You will need to have the kernel source available to compile ulogd.
    -
    -Download the ulod tar file and:
    - -
      -
    1. Be sure that /usr/src/linux is linked to your kernel source tree
      -
      2. -
    2. cd /usr/local/src (or wherever you do your builds)
      3. -
    3. tar -zxf source-tarball-that-you-downloaded
      4. -
    4. cd ulogd-version
      -
      5. -
    5. ./configure
      6. -
    6. make
      7. -
    7. make install
      -
      8. - -
    - If you are like me and don't have a development environment on your firewall, - you can do the first six steps on another system then either NFS mount -your /usr/local/src directory or tar up the /usr/local/src/ulogd-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.
    +
    + You will need to have the kernel source available to compile ulogd.

    - You will need to change all instances of log levels (usually 'info') in -your configuration files to 'ULOG' - this includes entries in the policy, + Download the ulod tar file and:
    + +
      +
    1. Be sure that /usr/src/linux is linked to your kernel source tree
      +
      2. +
    2. cd /usr/local/src (or wherever you do your builds)
      3. +
    3. tar -zxf source-tarball-that-you-downloaded
      4. +
    4. cd ulogd-version
      +
      5. +
    5. ./configure
      6. +
    6. make
      7. +
    7. make install
      +
      8. + +
    + If you are like me and don't have a development environment on your +firewall, you can do the first six steps on another system then either +NFS mount your /usr/local/src directory or tar up the /usr/local/src/ulogd-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.
    +
    + You will need to change all instances of log levels (usually 'info') in +your configuration files to 'ULOG' - this includes entries in the policy, rules and shorewall.conf files. Here's what I have:
    - + 
    	[root@gateway shorewall]# grep ULOG *
    	policy:loc  fw   REJECT  ULOG
    	policy:net  all  DROP    ULOG   10/sec:40
    	policy:all  all  REJECT  ULOG
    	rules:REJECT:ULOG loc net tcp 6667
    	shorewall.conf:TCP_FLAGS_LOG_LEVEL=ULOG
    	shorewall.conf:RFC1918_LOG_LEVEL=ULOG
    	[root@gateway shorewall]#
    - 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.
    - -

    Updated 1/11/2003 - Tom Eastep + 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.
    + +

    Updated 1/11/2003 - Tom Eastep

    - - - -

    Copyright © + +

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

    - +

    +
    diff --git a/STABLE/documentation/shorewall_mirrors.htm b/STABLE/documentation/shorewall_mirrors.htm index 396d6d401..bce067f09 100644 --- a/STABLE/documentation/shorewall_mirrors.htm +++ b/STABLE/documentation/shorewall_mirrors.htm @@ -1,93 +1,101 @@ - + - + - + - + Shorewall Mirrors - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +
    +

    Shorewall Mirrors

    -
    - -

    Remember that updates to the mirrors are often delayed - for 6-12 hours after an update to the primary rsync site. For HTML content, - the main web site (http://shorewall.sf.net) - is updated at the same time as the rsync site.

    - + +

    Remember that updates to the mirrors are often delayed + for 6-12 hours after an update to the primary rsync site. For HTML content, + the main web site (http://shorewall.sf.net) + is updated at the same time as the rsync site.

    +

    The main Shorewall Web Site is http://shorewall.sf.net - and is located in California, USA. It is mirrored at:

    - + href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net + and is located in California, USA. It is mirrored at:

    + - +

    The rsync site is mirrored via FTP at:

    - + - Search results and the mailing list archives are always fetched from -the site in Washington State.
    - -

    Last Updated 6/5/2003 - + +

    Last Updated 7/15/2003 - Tom Eastep

    - +

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

    +
    +

    +



    diff --git a/STABLE/documentation/shorewall_prerequisites.htm b/STABLE/documentation/shorewall_prerequisites.htm index c6b27fda9..09689ee34 100644 --- a/STABLE/documentation/shorewall_prerequisites.htm +++ b/STABLE/documentation/shorewall_prerequisites.htm @@ -1,68 +1,83 @@ - + - + - + - + Shorewall Prerequisites - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Shorewall Requirements

    -
    -
    - Shorewall Requires:
    - +
    + Shorewall Requires:
    +
      -
    • A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20. -With current releases of Shorewall, Traffic Shaping/Control requires at least -2.4.18.  Check here for kernel configuration - information. If you are looking for a firewall for use with -2.2 kernels, see the Seattle Firewall - site .
      • -
    • iptables 1.2 or later but beware version 1.2.3 -- see the Errata. WARNING: The - buggy iptables version 1.2.3 is included in RedHat 7.2 and you should - upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4 - is available A kernel that supports netfilter. I've tested with 2.4.2 - +2.4.20. With current releases of Shorewall, Traffic Shaping/Control requires +at least 2.4.18.  Check here for kernel configuration + information. If you are looking for a firewall for use with + 2.2 kernels, see the Seattle +Firewall site .
      • +
    • iptables 1.2 or later but beware version 1.2.3 -- see the + Errata. WARNING: + The buggy iptables version 1.2.3 is included in RedHat +7.2 and you should upgrade to iptables 1.2.4 prior to installing Shorewall. +Version 1.2.4 is available from RedHat - and in the Shorewall Errata.
      • -
    • Iproute ("ip" utility). The iproute package is included with -most distributions but may not be installed by default. The official -download site is Shorewall Errata.
      • +
    • Iproute ("ip" utility). The iproute package is included + with most distributions but may not be installed by default. The official + download site is ftp://ftp.inr.ac.ru/ip-routing. -
      • -
    • A Bourne shell or derivative such as bash or ash. This shell must - have correct support for variable expansion formats ${variable%pattern - }, ${variable%%pattern}, ${variable#pattern - } and ${variable##pattern}.
      • -
    • The firewall monitoring display is greatly improved if you have - awk (gawk) installed.
      • - + +
    • A Bourne shell or derivative such as bash or ash. This shell + must have correct support for variable expansion formats ${variable%pattern + }, ${variable%%pattern}, ${variable#pattern + } and ${variable##pattern}.
      • +
    • Your shell must produce a sensible result when a number n (128 <= +n <= 255) is left shifted by 24 bits. You can check this at a shell prompt +by:
      • + +
        +
      • echo $((128 << 24))
        +
        • +
      • The result must be either 2147483648 or -2147483648.
        +
        • + +
      +
    • The firewall monitoring display is greatly improved if you +have awk (gawk) installed.
      • +
    - -

    Last updated 3/19/2003 - Last updated 7/8/2003 - Tom Eastep

    - +

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

    +
    +
    +

    +



    diff --git a/STABLE/documentation/shorewall_quickstart_guide.htm b/STABLE/documentation/shorewall_quickstart_guide.htm index 80dde2b5b..b9c4fd546 100644 --- a/STABLE/documentation/shorewall_quickstart_guide.htm +++ b/STABLE/documentation/shorewall_quickstart_guide.htm @@ -1,308 +1,357 @@ - + - + - + - + Shorewall QuickStart Guide - + + - + - - - - - - + bgcolor="#3366ff" height="90"> + + + + + +
    - -

    Shorewall QuickStart Guides - (HOWTO's)
    - Version 4.0

    -
    + +

    Shorewall QuickStart Guides + (HOWTO's)
    +

    +
    - -

    With thanks to Richard who reminded me once again that we -must all first walk before we can run.
    - The French Translations are courtesy of Patrice Vetsel
    -

    - + +

    With thanks to Richard who reminded me once again that +we must all first walk before we can run.
    + The French Translations are courtesy of Patrice Vetsel
    +

    +

    The Guides

    - -

    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:

    - - - -

    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 (See - Index Below) 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.

    - -
      - -
    - -

    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.

    - -
      -
    • Aliased (virtual) Interfaces - (e.g., eth0:0)
      -
      • -
    • Blacklisting - -
        -
      • Static Blacklisting using /etc/shorewall/blacklist
        • -
      • Dynamic Blacklisting using /sbin/shorewall
        • - -
      -
      • -
    • Common configuration file - features - -
      • -
    • Configuration - File Reference Manual - -
      • -
    • DHCP
      • -
    • ECN Disabling by host - or subnet
      -
      • -
    • Extension Scripts - (How to extend Shorewall without modifying Shorewall code through the - use of files in /etc/shorewall -- /etc/shorewall/start, /etc/shorewall/stopped, - etc.)
      • -
    • Fallback/Uninstall
      • -
    • Firewall Structure
      • -
    • Kernel Configuration
      • -
    • Logging
      -
      • -
    • MAC Verification
      -
      • -
    • My Shorewall - Configuration (How I personally use Shorewall)
      -
      • -
    • 'Ping' Management
      -
      • -
    • Port Information - -
        -
      • Which applications use which ports
        • -
      • Ports used by Trojans
        • - -
      -
      • -
    • Proxy ARP
      • -
    • Samba
      • -
    • Shorewall Setup Guide
      -
      • - + +

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

      + +

      If you have a single public IP address:

      + +
      + +

      If you have more than one public IP +address:
      +

      +
      The Shorewall Setup Guide +(See Index Below) 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.
      + +
        + +
      + +

      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.

      + + - + -
    • Starting/stopping the Firewall
      • - +
        -
      • Description of all /sbin/shorewall commands
        • -
      • How to safely test a Shorewall configuration - change
        -
        • - +
      • Description of all /sbin/shorewall commands
        • +
      • How to safely test a Shorewall configuration + change
        +
        • +
      -
    • Static NAT
      • -
    • Squid as a Transparent - Proxy with Shorewall
      -
      • -
    • Traffic -Shaping/QOS
      • -
    • VPN - - - +

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

      - -

      Last modified 5/18/2003 - Tom Eastep

      - -

      Copyright 2002, 2003 Thomas M. - Eastep
      -

      -
      -
      -
      -
      + +

      Last modified 7/18/2003 - Tom Eastep

      + +

      Copyright 2002, 2003 Thomas M. + Eastep
      +


      diff --git a/STABLE/documentation/shorewall_setup_guide.htm b/STABLE/documentation/shorewall_setup_guide.htm index 08fb15740..78a7b3985 100644 --- a/STABLE/documentation/shorewall_setup_guide.htm +++ b/STABLE/documentation/shorewall_setup_guide.htm @@ -1,2613 +1,2655 @@ - + - + - + - + Shorewall Setup Guide - + - -

      Shorewall Setup Guide

      - -

      1.0 Introduction
      - 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 (ARP)
      - 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

      -
      - -

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

      - -

      Shorewall requires that the iproute/iproute2 package be 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 - .

      - -

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

      - -

      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:

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

      Shorewall Setup Guide

      +
      - -

      Zones are defined in the /etc/shorewall/zones - 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.

      - -

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

      - -

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

      - +
      + +

      1.0 Introduction
      + 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 (ARP)
      + 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

      +
      + +

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

      + +

      Shorewall requires that the iproute/iproute2 package be 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 + .

      + +

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

      + - -

      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:

      - + +

      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.

      + +

      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:

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

      Zones are defined in the /etc/shorewall/zones + 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.

      + +

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

      + +

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

      + + + +

      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:

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

      - -

      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.

      - + +

      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.

      + +

      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.

      +

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

      - -
      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Source ZoneDestination ZonePolicyLog LevelLimit:Burst
      locnetACCEPT  
      netallDROPinfo 
      allallREJECTinfo 
      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 (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. - +
      4. allow all connection requests from your local network + to the internet
        5. +
      5. 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).
        6. +
      6. 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.
        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.

      +

      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.

      - + +

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

      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.

      - + +

      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 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 Linux networking -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 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:

      - -
      + +

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

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

      -
      - -
      -
      +
      + +
      +

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

      - +     You may define more complicated zones using the /etc/shorewall/hosts file but in most + 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 you are going to use the rest of your addresses. Before we tackle -that question though, some background is in order.

      - -

      If you are thoroughly familiar with IP addressing and routing, - 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.

      - + +

      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 you are going to use the rest of your addresses. Before we +tackle that question though, some background is in order.

      + +

      If you are thoroughly familiar with IP addressing and routing, + 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:

      - -
      + +

      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:

      + +

      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 - came in three sizes (there were also Class D networks but they were -used differently):

      - -
      + +

      You will still hear the terms "Class A network", "Class B + network" and "Class C network". In the early days of IP, networks + only came in three sizes (there were also Class D networks but they +were used differently):

      + +

      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 a number that when logically ANDed with an address isolates the network - 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!). - 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.

      - -

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

      - +
      + +

      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 a number that when logically ANDed with an address isolates +the network 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!). + 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.

      + +

      A subnetwork (often referred to as a subnet) is + 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. -

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

        -
        4. -
      4. -

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

        -
        5. -
      5. -

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

        -
        6. - + +
      6. +

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

        +
        7. +
      7. +

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

        +
        8. +
      8. +

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

        +
        9. +
      - -

      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.

      - -

      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:

      - -
      + +

      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.

      + +

      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:

      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      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 derive the following one which is a little easier to use.

      - -
      +
      + +

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

      - -

      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:

      - -
      -

      11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 - = 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 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 "a.b.c.d/v" using CIDR Notation. 

      - +
      + +

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

      + +

      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:

      + +
      +

      11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 + = 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 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 "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.

      - -
      +
      + +

      There are two degenerate subnets that need mentioning; namely, + 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.

      - +
      + +

      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.

      - + +

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

      + +

      Beginning with Shorewall 1.4.6, /sbin/shorewall supports an +ipcalc command that automatically calculates information about a [sub]network.
      +

      + +

      Example 1:
      +

      + +
      + 
      ipcalc 10.10.10.0/25
         CIDR=10.10.10.0/25
         NETMASK=255.255.255.128
         NETWORK=10.10.10.0
         BROADCAST=10.10.10.127
      +
      + Example 2 +
      + 
      ipcalc 10.10.10.0 255.255.255.128
         CIDR=10.10.10.0/25
         NETMASK=255.255.255.128
         NETWORK=10.10.10.0
         BROADCAST=10.10.10.127
      +
      +

      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:

      - -
      -
      + +

      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.

      - -

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

      - +
      +
      + +

      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.

      + +

      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.

        -
        • -
      • -

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

        - +
      • +

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

        +
        • +
      • +

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

        +
        • +
      • +

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

        +
          -
        • -

          If the 'Gateway' column is non-zero, the packet is - 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.

          -
          • - +
        • + +

          If the 'Gateway' column is non-zero, the packet is + 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.

          +
          • +
        -
        • -
      • -

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

        -
        • - + +
      • +

        Otherwise, the above steps are repeated on the next entry + 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:

      - -
      -
      + +

      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:

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

      + +

      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.

      - +

      4.4 Address Resolution Protocol (ARP)

      - -

      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:

      - -
      -
      + +

      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:

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

      -
      - -
      -

      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:

      -
      - -
      -
      -
      + +
      +

      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:

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

      - -
      -
      +
      +
      +
      + +

      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 information we saw using tcpdump above.

      - +
      +
    + +

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

    - -
    + href="http://www.iana.org">Internet Assigned Number Authority (IANA) + 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 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 - forward packets which have an RFC-1918 destination address. This is - understandable given that anyone can select any of these addresses - for their private use.

    -
    - -
    -

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

    -
    - -
    +
    + +
    +

    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. +This is understandable 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:

    +
    + +
      -
    • -

      As the IPv4 address space becomes depleted, more and -more organizations (including ISPs) are beginning to use RFC 1918 addresses - 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 - a VPN relationship.

      -
      • - +
    • +

      As the IPv4 address space becomes depleted, more and more + organizations (including ISPs) are beginning to use RFC 1918 addresses + 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 + 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.

    -
    - -
    +
    + +
    +

    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.

    +
    + +

    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:

    -
    - -
    +
    + +
    +

    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:

    +
    + +
      -
    1. -

      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.

      -
      2. -
    2. -

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

      -
      3. - +
    3. +

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

      +
      4. +
    4. +

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

      +
      5. +
    -
    - -
    -

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

    - +
    + +
    +

    In the subsections that follow, we'll look at each of these + 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:
    -

    - +     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
      -
      • - +
    • NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
      • +
    • 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 +

    + +
    +

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

    -
    - -
    -

    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:

    -
    - -
    -
    +

    +
    + +
    +

    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.

    +
    + +
    +

    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:

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

    -
    - -
    -

    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.

    -
    - -
    +
    + + +
    +

    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.

    +
    + +
    +

    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.

    +
    + +

    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.

    -
    - -
    -

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

    -
    - -
    +
    + +
    +

    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.

    +
    + +
    +

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

    +
    + +
      -
    • -

      Source Network Address Translation (SNAT). -

      -
      • -
    • -

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

      -
      • -
    • +
    • +

      Source Network Address Translation (SNAT). +

      +
      • +
    • +

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

      +
      • +

    • Proxy ARP.

      -
      • -
    • -

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

      -
      • - + +
    • +

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

      +
      • +
    -
    - -
    -

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

    -
    - -
    +
    + +
    +

    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 the RFC 1918 address of A and forwards the response +

    + +
    +

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

    -
    - -
    +
    + +
    +

    Let's suppose that you decide to use SNAT on your local zone + and use public address 192.0.2.176 as both your firewall's external + IP address and the source IP address of internet requests sent from + that zone.

    +
    + +

    -

    -
    - -
    The local zone has been subnetted as 192.168.201.0/29 - (netmask 255.255.255.248).
    - + + + +
    The local zone has been subnetted as 192.168.201.0/29 + (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 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.

    -
    - -
    +
    +
    + +
    +

    This example used the normal technique of assigning the same + public IP address for the firewall external interface and for SNAT. + If you wanted to use a different IP address, you would either have + to use your distributions network configuration tools to add that +IP address to the external interface or you could set ADD_SNAT_ALIASES=Yes + in /etc/shorewall/shorewall.conf and Shorewall will add the address for + you.

    +
    + +

    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.

    -
    - -
    +
    + +
    +

    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.

    +
    + +

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

    -
    - -
    -

    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.

    -
    - -
    + +
    + +
    +

    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.

    +
    + +
    +

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

      -
      • - +
    • +

      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.

    -
    - -
    +
    + +
    +

    Let suppose that we decide to use Proxy ARP on the DMZ in + 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 - on the firewall. That address and netmask isn't relevant - just be - sure it doesn't overlap another subnet that you've defined.
    - +

    + + +
    Here, we've assigned the IP addresses 192.0.2.177 to + system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned + an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface + on the firewall. That address and netmask isn't relevant - just +be sure it doesn't overlap another subnet that you've defined.
    +
     
    - +
    -     The Shorewall configuration of Proxy ARP is done using -the /etc/shorewall/proxyarp file.
    - -
    -
    +     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.
    -

    - -

    The ethernet interfaces on DMZ 1 and DMZ 2 should be configured - to have the IP addresses shown but should have the same default gateway - as the firewall itself -- namely 192.0.2.254. In other words, they should - be configured just like they would be if they were parallel to the firewall - rather than behind it.
    -

    - -

    NOTE: Do not add the Proxy ARP'ed address(es) - (192.0.2.177 and 192.0.2.178 in the above example)  to the external interface - (eth0 in this example) of the firewall.
    -

    - + +
    + +
    +

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

    + +

    The ethernet interfaces on DMZ 1 and DMZ 2 should be configured + to have the IP addresses shown but should have the same default gateway + as the firewall itself -- namely 192.0.2.254. In other words, they should + be configured just like they would be if they were parallel to the firewall + rather than behind it.
    +

    + +

    NOTE: Do not add the Proxy ARP'ed address(es) + (192.0.2.177 and 192.0.2.178 in the above example)  to the external interface + (eth0 in this example) of the firewall.
    +

    +
    -
    - -
    +
    + +

    -
    - -
    -
    -

    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. There are a couple of things that you can try:
    -

    - +
    + +
    +
    +

    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. There are a couple of things that you can try:
    +

    +
      -
    1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP - Illustrated, Vol 1 reveals that a
      -
      - "gratuitous" ARP packet should cause the ISP's router to refresh -their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting -the MAC address for its own IP; in addition to ensuring that the IP address - isn't a duplicate,...
      -
      - "if the host sending the gratuitous ARP has just changed its hardware - address..., this packet causes any other host...that has an entry in its - cache for the old hardware address to update its ARP cache entry accordingly."
      -
      - Which is, of course, exactly what you want to do when you switch - a host from being exposed to the Internet to behind Shorewall using proxy - ARP (or static NAT for that matter). Happily enough, recent versions of - Redhat's iputils package include "arping", whose "-U" flag does just that:
      -
      -     arping -U -I <net if> <newly - proxied IP>
      -     arping -U -I eth0 66.58.99.83 # for - example
      -
      - Stevens goes on to mention that not all systems respond correctly - to gratuitous ARPs, but googling for "arping -U" seems to support the -idea that it works most of the time.
      -
      -
      2. -
    2. 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.
      3. - +
    3. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP + Illustrated, Vol 1 reveals that a
      +
      + "gratuitous" ARP packet should cause the ISP's router to refresh + their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting + the MAC address for its own IP; in addition to ensuring that the IP +address isn't a duplicate,...
      +
      + "if the host sending the gratuitous ARP has just changed its +hardware address..., this packet causes any other host...that has an +entry in its cache for the old hardware address to update its ARP cache +entry accordingly."
      +
      + Which is, of course, exactly what you want to do when you switch + a host from being exposed to the Internet to behind Shorewall using proxy + ARP (or static NAT for that matter). Happily enough, recent versions +of Redhat's iputils package include "arping", whose "-U" flag does just +that:
      +
      +     arping -U -I <net if> <newly + proxied IP>
      +     arping -U -I eth0 66.58.99.83 # +for example
      +
      + Stevens goes on to mention that not all systems respond correctly + to gratuitous ARPs, but googling for "arping -U" seems to support the + idea that it works most of the time.
      +
      +
      4. +
    4. 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.
      5. +
    - 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:
    - -
    + 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:
    + +
    	tcpdump -nei eth0 icmp
    -
    - -
    -

    Now from 192.0.2.177, ping the ISP's gateway (which we - will assume is 192.0.2.254):

    -
    - -
    +
    + +
    +

    Now from 192.0.2.177, ping the ISP's gateway (which we + will assume 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 still associates 192.0.2.177 with the NIC -in DMZ 1 rather than with the firewall's eth0.

    -
    - -
    +
    + +
    +

    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 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 (Source Network Address - Translation) occurs and on incoming connections DNAT (Destination -Network Address Translation) occurs. Let's go back to our earlier example -involving your daughter's web server running on system Local 3.

    -
    - -
    +
    + +
    +

    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 (Source Network +Address Translation) occurs and on incoming connections DNAT (Destination + Network Address Translation) 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:

    -
    - -
    -
    +

    +
    + +
    +

    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:

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

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

    -
    - -
    + +
    + +
    +

    With this entry in place, you daughter has her own 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  
    -
    -
    - -
    -
    -
    -

    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 static NAT, -it will probably be HOURS before that system can communicate with the -internet. There are a couple of things that you can try:
    -

    - + +
    + +
    +
    +
    +

    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 static + NAT, it will probably be HOURS before that system can communicate +with the internet. There are a couple of things that you can try:
    +

    +
      -
    1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP Illustrated, - Vol 1 reveals that a
      -
      - "gratuitous" ARP packet should cause the ISP's router to refresh -their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting -the MAC address for its own IP; in addition to ensuring that the IP address - isn't a duplicate,...
      -
      - "if the host sending the gratuitous ARP has just changed its hardware - address..., this packet causes any other host...that has an entry in its - cache for the old hardware address to update its ARP cache entry accordingly."
      -
      - Which is, of course, exactly what you want to do when you switch - a host from being exposed to the Internet to behind Shorewall using proxy - ARP (or static NAT for that matter). Happily enough, recent versions of - Redhat's iputils package include "arping", whose "-U" flag does just that:
      -
      -     arping -U -I <net if> <newly - proxied IP>
      -     arping -U -I eth0 66.58.99.83 # for - example
      -
      - Stevens goes on to mention that not all systems respond correctly - to gratuitous ARPs, but googling for "arping -U" seems to support the -idea that it works most of the time.
      -
      -
      2. -
    2. 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.
      3. +
    3. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP + Illustrated, Vol 1 reveals that a
      +
      + "gratuitous" ARP packet should cause the ISP's router to refresh + their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting + the MAC address for its own IP; in addition to ensuring that the IP +address isn't a duplicate,...
      +
      + "if the host sending the gratuitous ARP has just changed its +hardware address..., this packet causes any other host...that has an +entry in its cache for the old hardware address to update its ARP cache +entry accordingly."
      +
      + Which is, of course, exactly what you want to do when you switch + a host from being exposed to the Internet to behind Shorewall using proxy + ARP (or static NAT for that matter). Happily enough, recent versions +of Redhat's iputils package include "arping", whose "-U" flag does just +that:
      +
      +     arping -U -I <net if> <newly + proxied IP>
      +     arping -U -I eth0 66.58.99.83 # +for example
      +
      + Stevens goes on to mention that not all systems respond correctly + to gratuitous ARPs, but googling for "arping -U" seems to support the + idea that it works most of the time.
      +
      +
      4. +
    4. 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.
      5. +
    - 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 209.0.2.179. On the firewall, run tcpdump - as follows:
    - -
    + 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 209.0.2.179. On the firewall, +run tcpdump as follows:
    + +
    	tcpdump -nei eth0 icmp
    -
    - -
    -

    Now from the 192.168.201.4, ping the ISP's gateway (which -we will assume is 192.0.2.254):

    -
    - -
    +
    + +
    +

    Now from the 192.168.201.4, ping the ISP's gateway (which + we will assume 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.179 > 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.179 : 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 still associates 192.0.2.179 with the NIC -in the local zone rather than with the firewall's eth0.

    -
    - +
    + +
    +

    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 still associates 192.0.2.179 with +the NIC in the local zone rather than with the firewall's eth0.

    +
    +

    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 to pass through the firewall, the - way to allow connection requests through 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

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

    +
    + +
    +

    NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't + 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:

    -
    - -
    -
    +
    +
    + +
    +

    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:

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

    -
    - -
    -
    +
    +
    + +
    +

    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.

    -
    - -
    -
    +
    +
    + +
    +

    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.

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

    -
    - -
    +
    + +
    +

    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.

    -
    - -
    -

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

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

    -
    - -
    -
    +
    +
    + +
    +

    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.

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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; };
    };
    -
    +
    +
    -
    +
    +

    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; };
    };
    +
    + + 
    #
    # 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.0/8;
    			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";
    	};
     (or status NAT for that matter)
    	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).

    - -

    db.192.0.2.176 - This is the reverse zone for the firewall's - external interface

    - -
    +
    + +
    + +
    +

    Here are the files in /var/named (those not shown are usually + included in your bind disbribution).

    + +

    db.192.0.2.176 - This is the reverse zone for the firewall's + 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 -
    +
    +
    + +
    +
    db.192.0.2.177 - This is the reverse zone for the www/DNS + 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 -
    +
    +
    +
    + +
    +
    db.192.0.2.178 - This is the reverse zone for the mail + 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 -
    +
    +
    +
    + +
    +
    db.192.0.2.179 - This is the reverse zone for daughter's + 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

    -
    - -
    -
    +
    +
    + +
    +

    int/db.192.168.201 - Reverse zone for the local net. This + 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

    -
    - -
    -
    -
    +
    +
    + +
    +

    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

    -
    - -
    -

    The installation procedure configures - 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".

    -
    - -
    +
    +
    +
    + +
    +

    7.0 Starting and Stopping + Your Firewall

    +
    + +
    +

    The installation procedure configures + 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".

    +
    + +

    -     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 - 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 6/7/2003 - + + +

    + +

    Last updated 7/6/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 - Thomas M. Easte
    -

    + +

    Copyright 2002, 2003 + Thomas M. Easte
    +

    +

    diff --git a/STABLE/documentation/sourceforge_index.htm b/STABLE/documentation/sourceforge_index.htm index 22495a654..2d4f02945 100644 --- a/STABLE/documentation/sourceforge_index.htm +++ b/STABLE/documentation/sourceforge_index.htm @@ -2,488 +2,646 @@ - + + - Shoreline Firewall (Shorewall) 1.3 + Shoreline Firewall (Shorewall) 1.4 - + + - + + + bgcolor="#3366ff"> - + - + - - + + - - + - - + + +
    - - - - -

    Shorewall 1.4 "iptables made easy"

    +     		+ (Shorewall Logo) +
    		-


    -

    -
    -
    - -
    -
    + + +
    +
    - + - + - + + - + - + - - + + +
    + - + + +

    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.

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

    + 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, 2003 Thomas M. Eastep

    - -

    Running Shorewall on Mandrake with a two-interface setup?

    - If so, almost NOTHING on this site will apply directly - to your setup. If you want to use the documentation that you find here, - it is best if you uninstall what you have and install a setup that matches - the documentation on this site. See the Two-interface - QuickStart Guide for details.
    - + +

    This is the Shorewall 1.4 Web Site

    + The information on this site applies only to 1.4.x releases of Shorewall. + For older versions:
    + +
      +
    • The 1.3 site is here.
      • +
    • The 1.2 site is here.
      +
      • + +
    +

    Getting Started with Shorewall

    - New to Shorewall? Start by selecting the QuickStart Guide that most closely - match your environment and follow the step by step instructions.
    + New to Shorewall? Start by selecting + the QuickStart + Guide that most closely match your environment and +follow the step by step instructions.
    + +

    Looking for Information?

    + The Documentation + Index is a good place to start as is the Quick Search to your right. + +

    Running Shorewall on Mandrake with a two-interface setup?

    + If so, the documentation on this site +will not apply directly to your setup. If you want to use the documentation + that you find here, you will want to consider uninstalling what you +have and installing a setup that matches the documentation on +this site. See the Two-interface QuickStart + Guide for details. + +

    - + +

    News

    - - - -

    6/17/2003 - Shorewall-1.4.5 (New) -

    - -

    Problems Corrected:
    -

    - -
      -
    1. The command "shorewall debug try <directory>" now correctly -traces the attempt.
      2. -
    2. The INCLUDE directive now works properly in the zones file; previously, -INCLUDE in that file was ignored.
      3. -
    3. /etc/shorewall/routestopped records with an empty second column -are no longer ignored.
      -
      4. -
    - -

    New Features:
    -

    - -
      -
    1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may -now contain a list of addresses. If the list begins with "!' then the rule -will take effect only if the original destination address in the connection -request does not match any of the addresses listed.
      2. -
    -

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 - (New) -

    - The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and - iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems - have been encountered with this set of software. The Shorewall version is - 1.4.4b plus the accumulated changes for 1.4.5. -

    6/8/2003 - Updated Samples (New) -

    - -

    Thanks to Francesca Smith, the samples have been updated to Shorewall - version 1.4.4.

    -

    5/29/2003 - Shorewall-1.4.4b

    - -

    Groan -- This version corrects a problem whereby the --log-level - was not being set when logging via syslog. The most commonly reported symptom - was that Shorewall messages were being written to the console even though - console logging was correctly configured per FAQ - 16.
    -

    - -

    5/27/2003 - Shorewall-1.4.4a

    - The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed - out that the code in 1.4.4 restricts the length of short zone names to -4 characters. I've produced version 1.4.4a that restores the previous 5-character - limit by conditionally omitting the log rule number when the LOGFORMAT -doesn't contain '%d'. -

    5/23/2003 - Shorewall-1.4.4 -

    - I apologize for the rapid-fire releases but since there is a potential - configuration change required to go from 1.4.3a to 1.4.4, I decided to -make it a full release rather than just a bug-fix release.
    -
    -     Problems corrected:
    - -
    None.
    -
    -     New Features:
    -     -
      -
    1. A REDIRECT- rule target has been added. This target behaves - for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter - nat table REDIRECT rule is added but not the companion filter table ACCEPT - rule.
      -
      -
      2. -
    2. The LOGMARKER variable has been renamed LOGFORMAT and -has been changed to a 'printf' formatting template which accepts three -arguments (the chain name, logging rule number and the disposition). To -use LOGFORMAT with fireparse (http://www.fireparse.com), - set it as:
      -  
      -        LOGFORMAT="fp=%s:%d a=%s "
      -  
      - CAUTION: /sbin/shorewall uses the leading part of the -LOGFORMAT string (up to but not including the first '%') to find log messages -in the 'show log', 'status' and 'hits' commands. This part should not -be omitted (the LOGFORMAT should not begin with "%") and the leading part -should be sufficiently unique for /sbin/shorewall to identify Shorewall -messages.
      -
      -
      3. -
    3. When logging is specified on a DNAT[-] or REDIRECT[-] -rule, the logging now takes place in the nat table rather than in the filter -table. This way, only those connections that actually undergo DNAT or redirection - will be logged.
      4. - -
    - -

    5/20/2003 - Shorewall-1.4.3a -
    -

    - This version primarily corrects the documentation included in the - .tgz and in the .rpm. In addition:
    - - -
      -
    1. (This change is in 1.4.3 but is not documented) If -you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will -return reject replies as follows:
      -    a) tcp - RST
      -    b) udp - ICMP port unreachable
      -    c) icmp - ICMP host unreachable
      -    d) Otherwise - ICMP host prohibited
      - If you are running earlier software, Shorewall will follow it's - traditional convention:
      -    a) tcp - RST
      -    b) Otherwise - ICMP port unreachable
      2. -
    2. UDP port 135 is now silently dropped in the common.def - chain. Remember that this chain is traversed just before a DROP or REJECT - policy is enforced.
      -
      3. - - -
    - - -

    5/18/2003 - Shorewall 1.4.3
    -

    -     Problems Corrected:
    -     - -
      -
    1. There were several cases where Shorewall would fail - to remove a temporary directory from /tmp. These cases have been corrected.
      2. -
    2. The rules for allowing all traffic via the loopback - interface have been moved to before the rule that drops status=INVALID - packets. This insures that all loopback traffic is allowed even if Netfilter - connection tracking is confused.
      3. - - -
    -     New Features:
    -     - -
      -
    1.  IPV6-IPV4 - (6to4) tunnels are now supported in the /etc/shorewall/tunnels -file.
      2. -
    2. You may now change the leading portion -of the --log-prefix used by Shorewall using the LOGMARKER variable in -shorewall.conf. By default, "Shorewall:" is used.
      -
      3. - - -
    - - -

    5/10/2003 - Shorewall Mirror in Asia
    -

    - Ed Greshko has established a mirror in Taiwan -- Thanks -Ed! - -

    5/8/2003 - Shorewall Mirror in Chile  

    - - -

    Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
    -

    - - -

    4/26/2003 - lists.shorewall.net Downtime  

    - - - -

    The list server will be down this morning for upgrade to RH9.0.
    -

    - - - -

    4/21/2003 - Samples updated for Shorewall version 1.4.2 -

    - +

    7/20/2003 - Shorewall-1.4.6 (New) +
    +

    -

    Thanks to Francesca Smith, the sample configurations are now upgraded - to Shorewall version 1.4.2.

    - - - -

    4/12/2002 - Greater Seattle Linux Users Group Presentation -

    - - +

    Problems Corrected:
    +

    -
    This morning, I gave a Shorewall presentation to GSLUG. The presentation - is in HTML format but was generated from Microsoft PowerPoint -and is best viewed using Internet Explorer (although Konqueror also -seems to work reasonably well as does Opera 7.1.0). Neither Opera -6 nor Netscape work well to view the presentation.
    - +
      +
    1. A problem seen on RH7.3 systems where Shorewall encountered + start errors when started using the "service" mechanism has been worked + around.
      +
      +
      2. +
    2. Where a list of IP addresses appears in the DEST column of +a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the + nat table (one for each element in the list). Shorewall now correctly creates + a single DNAT rule with multiple "--to-destination" clauses.
      +
      +
      3. +
    3. Corrected a problem in Beta 1 where DNS names containing a +"-" were mis-handled when they appeared in the DEST column of a rule.
      +
      +
      4. +
    4. A number of problems with rule parsing have been corrected. + Corrections involve the handling of "z1!z2" in the SOURCE column as well +as lists in the ORIGINAL DESTINATION column.
      +
      +
      5. +
    5. The message "Adding rules for DHCP" is now suppressed if there +are no DHCP rules to add.
      6. +
    +

    Migration Issues:
    +

    + +
      +
    1. In earlier versions, an undocumented feature allowed entries + in the host file as follows:
      +
      +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 + to allow entries of the following format:
      +
      +     z   eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      2. +
    2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options +have been removed from /etc/shorewall/shorewall.conf. These capabilities +are now automatically detected by Shorewall (see below).
      +
      3. + +
    + +

    New Features:
    +

    +
      +
    1. A 'newnotsyn' interface option has been added. This option + may be specified in /etc/shorewall/interfaces and overrides the setting + NEWNOTSYN=No for packets arriving on the associated interface.
      +
      +
      2. +
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for + address ranges.
      +
      +
      3. +
    3. Shorewall can now add IP addresses to subnets other than + the first one on an interface.
      +
      +
      4. +
    4. DNAT[-] rules may now be used to load balance (round-robin) + over a set of servers. Servers may be specified in a range of addresses + given as <first address>-<last address>.
      +
      + Example:
      +
      +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
      +
      +
      5. +
    5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration + options have been removed and have been replaced by code that detects +whether these capabilities are present in the current kernel. The output +of the start, restart and check commands have been enhanced to report the +outcome:
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      + Verifying Configuration...
      +
      +
      6. +
    6. Support for the Connection Tracking Match Extension has + been added. This extension is available in recent kernel/iptables releases + and allows for rules which match against elements in netfilter's connection + tracking table. Shorewall automatically detects the availability of this + extension and reports its availability in the output of the start, restart + and check commands.
      +
      + Shorewall has detected the following iptables/netfilter capabilities:
      +    NAT: Available
      +    Packet Mangling: Available
      +    Multi-port Match: Available
      +    Connection Tracking Match: Available
      + Verifying Configuration...
      +
      + If this extension is available, the ruleset generated by Shorewall + is changed in the following ways:
      7. + +
        +
      • To handle 'norfc1918' filtering, Shorewall will not +create chains in the mangle table but will rather do all 'norfc1918' +filtering in the filter table (rfc1918 chain).
        • +
      • Recall that Shorewall DNAT rules generate two netfilter + rules; one in the nat table and one in the filter table. If the Connection + Tracking Match Extension is available, the rule in the filter table is +extended to check that the original destination address was the same as +specified (or defaulted to) in the DNAT rule.
        +
        +
        • + +
      +
    7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
      +
      +
      8. +
    8. An 'ipcalc' command has been added to /sbin/shorewall.
      +
      +       ipcalc [ <address> <netmask> | <address>/<vlsm> + ]
      +
      + Examples:
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
      +          CIDR=192.168.1.0/24
      +          NETMASK=255.255.255.0
      +          NETWORK=192.168.1.0
      +          BROADCAST=192.168.1.255
      +       [root@wookie root]#
      +
      + Warning:
      +
      + If your shell only supports 32-bit signed arithmatic (ash or dash), + then the ipcalc command produces incorrect information for IP addresses + 128.0.0.0-1 and for /1 networks. Bash should produce correct information + for all valid IP addresses.
      +
      +
      9. +
    9. An 'iprange' command has been added to /sbin/shorewall. +
      +
      +       iprange <address>-<address>
      +
      + This command decomposes a range of IP addressses into a list of network + and host addresses. The command can be useful if you need to construct +an efficient set of rules that accept connections from a range of network +addresses.
      +
      + Note: If your shell only supports 32-bit signed arithmetic (ash or + dash) then the range may not span 128.0.0.0.
      +
      + Example:
      +
      +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
      +       192.168.1.4/30
      +       192.168.1.8/29
      +       192.168.1.16/28
      +       192.168.1.32/27
      +       192.168.1.64/26
      +       192.168.1.128/25
      +       192.168.2.0/23
      +       192.168.4.0/22
      +       192.168.8.0/22
      +       192.168.12.0/29
      +       192.168.12.8/31
      +       [root@gateway root]#
      +
      +
      10. +
    10. A list of host/net addresses is now allowed in an entry + in /etc/shorewall/hosts.
      +
      + Example:
      +
      +     foo    eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      11. +
    11. The "shorewall check" command now includes the chain +name when printing the applicable policy for each pair of zones.
      +  
      +     Example:
      +  
      +         Policy for dmz to net is REJECT using chain all2all
      +  
      + This means that the policy for connections from the dmz to the internet +is REJECT and the applicable entry in the /etc/shorewall/policy was the all->all +policy.
      +
      +
      12. +
    12. Support for the 2.6 Kernel series has been added.
      +
      13. + +
    + + +
      + + +
    + + +

    7/15/2003 - New Mirror in Brazil (New) +
    +

    + Thanks to the folks at securityopensource.org.br, there is now a Shorewall + mirror in Brazil +

    6/17/2003 - Shorewall-1.4.5

    + + +

    Problems Corrected:
    +

    + + +
      +
    1. The command "shorewall debug try <directory>" + now correctly traces the attempt.
      2. +
    2. The INCLUDE directive now works properly in the +zones file; previously, INCLUDE in that file was ignored.
      3. +
    3. /etc/shorewall/routestopped records with an empty + second column are no longer ignored.
      +
      4. + + +
    + + +

    New Features:
    +

    + + +
      +
    1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] + rule may now contain a list of addresses. If the list begins with "!' + then the rule will take effect only if the original destination address + in the connection request does not match any of the addresses listed.
      2. + + +
    + + +

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 +

    + The firewall at shorewall.net has been upgraded to the 2.4.21 + kernel and iptables 1.2.8 (using the "official" RPM from netfilter.org). + No problems have been encountered with this set of software. The Shorewall + version is 1.4.4b plus the accumulated changes for 1.4.5. + + +

    6/8/2003 - Updated Samples

    + + +

    Thanks to Francesca Smith, the samples have been updated to Shorewall + version 1.4.4.

    + +

    +
      + + + +
    + + + +

    + + + + + +

    + + +
    - + + +
      - + + +
    -
    + - + +

    - + - + + +

    More News

    - + - + + +

    - + - + + +

    (Leaf Logo) - 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.14 and Kernel-2.4.20. You - can find their work at: http://leaf.sourceforge.net/devel/jnilo

    + 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.4.2 and Kernel-2.4.20. + You can find their work at: + http://leaf.sourceforge.net/devel/jnilo

    - Congratulations to Jacques and - Eric on the recent release of Bering 1.2!!! -
    + Congratulations to Jacques + and Eric on the recent release of Bering + 1.2!!!
    - + + +

    SourceForge Logo -

    - + + - + + +

    - + - + + +

    This site is hosted by the generous folks at SourceForge.net

    - + - + + +

    Donations

    -     		+ - + +
    - + + +


    - Note:     - Search is unavailable Daily 0200-0330 - GMT.
    -  

    + Note: + Search is unavailable Daily 0200-0330 GMT.
    +  

    - + + +

    Quick Search
    - -

    - +

    +
    - + + +

    Extended Search

    - -
    -
    -
    +
    -
    - + + + + bgcolor="#3366ff"> - + - + - + - + - - + + +
    + + - +

    -

    +

    - + + +


    - 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 6/17/2003 - Tom Eastep -
    + + +

    Updated 7/19/2003 - Tom Eastep +

    diff --git a/STABLE/documentation/standalone.htm b/STABLE/documentation/standalone.htm index 8e1a8dc14..6c044c207 100644 --- a/STABLE/documentation/standalone.htm +++ b/STABLE/documentation/standalone.htm @@ -1,426 +1,428 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
    + id="AutoNumber6" bgcolor="#3366ff" height="90"> +

    Standalone Firewall

    -
    - +

    Version 2.0.1

    - -

    Setting up Shorewall on a standalone Linux system is very + +

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

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

    Shorewall requires 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:

    - + +

    Shorewall requires 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 +     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 +     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 + href="http://www1.shorewall.net/pub/shorewall/Samples/">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 + +

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

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

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

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

    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:

    - -
    + +

    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  
    netall
    -     		DROPinfo 
    allallREJECTinfo 
    fwnetACCEPT  
    netall
    +     		DROPinfo 
    allallREJECTinfo 
    -
    - +
    +

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

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

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

    • +

      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 +

      • +
    • +

      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 +

    + +
    +

    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 +

    + +

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

    - -
    -

    If you wish to enable connections from the internet to your + +

    +

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

    -     At this point, edit /etc/shorewall/rules to add other connections +     At this point, edit /etc/shorewall/rules to add other connections as desired.

    -
    - -
    -

    Starting and Stopping Your Firewall

    - -
    + +
    +

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

    - -

    IMPORTANT: Users of the .deb +     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 +

    +
    + +
    +

    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 +

    + +
    +

    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 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Eastep

    -
    +
    +



    diff --git a/STABLE/documentation/standalone_fr.html b/STABLE/documentation/standalone_fr.html index 2adbb753d..4b21a122b 100755 --- a/STABLE/documentation/standalone_fr.html +++ b/STABLE/documentation/standalone_fr.html @@ -1,468 +1,470 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
    + id="AutoNumber6" bgcolor="#3366ff" height="90"> +

    Standalone Firewall

    -
    - +

    Version 2.0.1 Française

    - +

    Notes du traducteur :
    - Je ne prétends pas être un vrai traducteur dans le sens ou mon travail -n'est pas des plus précis (loin de là...). Je ne me suis pas attaché à une -traduction exacte du texte, mais plutôt à en faire une version française -intelligible par tous (et par moi). Les termes techniques sont la plupart -du temps conservés sous leur forme originale et mis entre parenthèses car -vous pouvez les retrouver dans le reste des documentations ainsi que dans -les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer -ce document VETSEL Patrice -(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à -Tom EASTEP pour son formidable outil et sa disponibilité)    .

    - -

    Mettre en place un système Linux en tant que firewall (écluse) -pour un petit réseau est une chose assez simple, si vous comprenez les bases -et suivez la documentation.

    - -

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il se -focalise sur ce qui est nécessaire pour configurer Shorewall, dans son utilisation -la plus courante :

    - + Je ne prétends pas être un vrai traducteur dans le sens ou mon travail +n'est pas des plus précis (loin de là...). Je ne me suis pas attaché à une +traduction exacte du texte, mais plutôt à en faire une version française intelligible +par tous (et par moi). Les termes techniques sont la plupart du temps conservés +sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver +dans le reste des documentations ainsi que dans les fichiers de configuration. +N?hésitez pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM +pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour +son formidable outil et sa disponibilité)    .

    + +

    Mettre en place un système Linux en tant que firewall (écluse) + pour un petit réseau est une chose assez simple, si vous comprenez les bases + et suivez la documentation.

    + +

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il +se focalise sur ce qui est nécessaire pour configurer Shorewall, dans son +utilisation la plus courante :

    +
      -
    • Un système Linux
      • -
    • Une seule adresse IP externe
      • -
    • Une connexion passant par un modem câble, ADSL, ISDN, Frame Relay, -rtc...
      • - +
    • Un système Linux
      • +
    • Une seule adresse IP externe
      • +
    • Une connexion passant par un modem câble, ADSL, ISDN, Frame Relay, + rtc...
      • +
    - -

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. Vous -pouvez voir si le paquet est installé en vérifiant la présence du programme -ip sur votre système de firewall. Sous root, utilisez la commande 'which' -pour rechercher le programme :

    - + +

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. +Vous pouvez voir si le paquet est installé en vérifiant la présence du programme + ip sur votre système de firewall. Sous root, utilisez la commande 'which' + pour rechercher le programme :

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

    Je vous recommande dans un premier temps de parcourir tout le guide pour -vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant -le changements dans votre configuration. Les points, où les changements dans -la configuration sont recommandées, sont signalés par une Je vous recommande dans un premier temps de parcourir tout le guide pour + vous familiariser avec ce qu'il va se passer, et de revenir au début en +effectuant le changements dans votre configuration. Les points, où les changements +dans la configuration sont recommandées, sont signalés par une - .

    - + .

    +

    - Si vous éditez vos fichiers de configuration sur un système Windows, vous - devez les sauver comme des fichiers Unix si votre éditeur supporte cette -option sinon vous devez les faire passer par dos2unix avant d'essayer de -les utiliser. De la même manière, si vous copiez un fichier de configuration -depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix -sur la copie avant de l'utiliser avec Shorewall.

    - + Si vous éditez vos fichiers de configuration sur un système Windows, vous + devez les sauver comme des fichiers Unix si votre éditeur supporte cette +option sinon vous devez les faire passer par dos2unix avant d'essayer de les +utiliser. De la même manière, si vous copiez un fichier de configuration depuis +votre disque dur Windows vers une disquette, vous devez lancer dos2unix sur +la copie avant de l'utiliser avec Shorewall.

    + - +

    Les Concepts de Shorewall

    - +

    - Les fichiers de configuration pour Shorewall sont situés dans le répertoire - /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec -quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez le one-interface sample, -un-tarez le (tar -zxvf one-interface.tgz) et copiez les fichiers vers /etc/shorewall - (Ils remplaceront les fichiers de même nom déjà existant dans /etc/shorewall + href="http://www1.shorewall.net/pub/shorewall/Samples/">one-interface sample, +un-tarez le (tar -zxvf one-interface.tgz) et copiez les fichiers vers /etc/shorewall + (Ils remplaceront les fichiers de même nom déjà existant dans /etc/shorewall installés lors de l'installation de Shorewall).

    - -

    Parallèlement à la description, je vous suggère de jeter un oeil à ceux -physiquement présents sur votre système -- chacun des fichiers contient des -instructions de configuration détaillées et des entrées par défaut.

    - -

    Shorewall voit le réseau où il tourne comme composé par un ensemble de -zones. Dans les fichiers de configuration fournis pour une unique interface, -une seule zone est définie :

    - + +

    Parallèlement à la description, je vous suggère de jeter un oeil à ceux + physiquement présents sur votre système -- chacun des fichiers contient +des instructions de configuration détaillées et des entrées par défaut.

    + +

    Shorewall voit le réseau où il tourne comme composé par un ensemble de + zones. Dans les fichiers de configuration fournis pour une unique +interface, une seule zone est définie :

    + - - - - - - - - - - - + + + + + + + + + + +
    NameDescription
    netThe Internet
    NameDescription
    netThe Internet
    - +

    Les zones de Shorewall sont définies dans /etc/shorewall/zones.

    - -

    Shorewall reconnaît aussi le système de firewall comme sa propre zone - -par défaut, le firewall lui-même est connu en tant que fw.

    - -

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées -en utilisant les termes de zones.

    - + +

    Shorewall reconnaît aussi le système de firewall comme sa propre zone +- par défaut, le firewall lui-même est connu en tant que fw.

    + +

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées + en utilisant les termes de zones.

    +
      -
    • Vous exprimez les politiques par défaut pour les connexions d'une -zone à une autre dans le fichier /etc/shorewall/policy - .
      • -
    • Vous définissez les exceptions à ces règles de politiques par défaut -dans le fichier /etc/shorewall/rules.
      • - +
    • Vous exprimez les politiques par défaut pour les connexions d'une +zone à une autre dans le fichier /etc/shorewall/policy + .
      • +
    • Vous définissez les exceptions à ces règles de politiques par défaut + dans le fichier /etc/shorewall/rules.
      • +
    - -

    Pour chacune des demandes de connexion entrantes dans le firewall, les -demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. -Si aucune des règles dans ce fichier ne correspondent, alors la première politique -dans /etc/shorewall/policy qui y correspond est appliquée. Si cette politique -est REJECT ou DROP la requête est alors comparée par rapport aux règles contenues -dans /etc/shorewall/common (l'archive d'exemple vous fournit ce fichier).

    - -

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive one-interface -a les politiques suivantes :

    - -
    + +

    Pour chacune des demandes de connexion entrantes dans le firewall, les + demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. + Si aucune des règles dans ce fichier ne correspondent, alors la première +politique dans /etc/shorewall/policy qui y correspond est appliquée. Si cette +politique est REJECT ou DROP la requête est alors comparée par rapport aux +règles contenues dans /etc/shorewall/common (l'archive d'exemple vous fournit +ce fichier).

    + +

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive one-interface + a les politiques suivantes :

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    fwnetACCEPT
    -
    -
    netall
    -     		DROPinfo
    -
    allallREJECTinfo
    -
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    fwnetACCEPT
    +
    +
    netall
    +     		DROPinfo
    +
    allallREJECTinfo
    +
    -
    - +
    +
    - Ces politiques vont : + Ces politiques vont :
      -
    1. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      2. -
    2. drop (ignorer) toutes les demandes de connexion depuis l'Internet +
    3. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      4. +
    4. drop (ignorer) toutes les demandes de connexion depuis l'Internet vers votre firewall
      5. -
    5. rejeter toutes les autres requêtes de connexion (Shorewall à besoin -de cette politique).
      6. - +
    6. rejeter toutes les autres requêtes de connexion (Shorewall à besoin + de cette politique).
      7. +
    - -

    A ce point, éditez votre /etc/shorewall/policy et faites y les changements -que vous désirez.

    - + +

    A ce point, éditez votre /etc/shorewall/policy et faites y les changements + que vous désirez.

    +

    Interface Externe

    - -

    Le firewall possède une seule interface réseau. Lorsque la -connexion Internet passe par un modem câble ou par un routeur ADSL (pas un -simple modem), l'External Interface (interface externe) sera l'adaptateur -ethernet (eth0) qui y est connecté à moins que vous vous connectiez -par Point-to-Point Protocol over Ethernet -(PPPoE) ou Point-to-Point TunnelingProtocol(PPTP) - dans ce cas l'interface externe sera ppp0. Si vous vous connectez -par un simple modem (RTC), votre interface externe sera aussi ppp0. - Si vous vous connectez en utilisant l'ISDN (numéris), votre interface externe -sera ippp0.

    - + +

    Le firewall possède une seule interface réseau. Lorsque la + connexion Internet passe par un modem câble ou par un routeur ADSL (pas +un simple modem), l'External Interface (interface externe) sera l'adaptateur + ethernet (eth0) qui y est connecté à moins que vous vous connectiez + par Point-to-Point Protocol over Ethernet + (PPPoE) ou Point-to-Point TunnelingProtocol(PPTP) + dans ce cas l'interface externe sera ppp0. Si vous vous connectez + par un simple modem (RTC), votre interface externe sera aussi ppp0. + Si vous vous connectez en utilisant l'ISDN (numéris), votre interface externe + sera ippp0.

    +

    - L'exemple de configuration de Shorewall pour une interface suppose que -votre interface externe est eth0. Si votre configuration est différente, -vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. - Puisque vous y êtes, vous pourriez parcourir la liste d'options qui sont -spécifiées pour l'interface. Quelques astuces :

    - + L'exemple de configuration de Shorewall pour une interface suppose que +votre interface externe est eth0. Si votre configuration est différente, + vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. + Puisque vous y êtes, vous pourriez parcourir la liste d'options qui sont + spécifiées pour l'interface. Quelques astuces :

    +
      -
    • -

      Si votre interface externe est ppp0 ou ippp0, - vous pouvez remplacer le "detect" dans la seconde colonne par un "-". -

      -
      • -
    • -

      Si votre interface externe est ppp0 ou ippp0 - ou bien si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" -de la liste d'option.

      -
      • - +
    • +

      Si votre interface externe est ppp0 ou ippp0, + vous pouvez remplacer le "detect" dans la seconde colonne par un "-". +

      +
      • +
    • +

      Si votre interface externe est ppp0 ou ippp0 + ou bien si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" + de la liste d'option.

      +
      • +
    - -
    + +

    Adresse IP

    -
    - -
    -

    La RFC 1918 définie plusieurs plage d'adresses IP privée (PrivateIP) -pour l'utilisation dans des réseaux privés :

    - -
    +
    + +
    +

    La RFC 1918 définie plusieurs plage d'adresses IP privée +(PrivateIP) pour l'utilisation dans des réseaux privés :

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

    Ces adresses sont parfois désignées comme étant non-routables - car les routeurs sur les backbones Internet ne font pas passer les paquets -dont les adresses de destinations sont définies dans la RFC 1918. Dans certains -cas, les fournisseurs (provider ou ISP) utilisent ces adresses et utilisent -le Network Address Translation afin de récrire les entêtes des paquets -lorsqu'ils les font circuler depuis ou vers l'Internet.

    - +
    + +

    Ces adresses sont parfois désignées comme étant non-routables + car les routeurs sur les backbones Internet ne font pas passer les paquets + dont les adresses de destinations sont définies dans la RFC 1918. Dans certains + cas, les fournisseurs (provider ou ISP) utilisent ces adresses et utilisent + le Network Address Translation afin de récrire les entêtes des paquets + lorsqu'ils les font circuler depuis ou vers l'Internet.

    +

    - Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface -externe et si elle est comprise dans une des plages précédentes, vous devriez -enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    -
    - -
    + Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface + externe et si elle est comprise dans une des plages précédentes, vous devriez + enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    +
    + +

    Permettre d'autres connexions

    -
    - -
    -

    Si vous désirez autoriser d'autres connexions depuis l'Internet -vers votre firewall, le format général est :

    -
    - -
    -
    +
    + +
    +

    Si vous désirez autoriser d'autres connexions depuis l'Internet + vers votre firewall, le format général est :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>
    +
    +
    -
    -
    - -
    -

    Exemple - Vous voulez faire tourner un serveur Web et un serveur -POP3 sur votre système de firewall :

    -
    - -
    -
    +
    +
    + +
    +

    Exemple - Vous voulez faire tourner un serveur Web et un +serveur POP3 sur votre système de firewall :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80
    -
    -
    ACCEPTnetfwtcp110
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80
    +
    +
    ACCEPTnetfwtcp110
    +
    +
    -
    -
    - -
    -

    Si vous ne savez pas quel port ou protocole une application -particulière utilise, regardez ici.

    -
    - -
    -

    Important: Je ne vous recommande pas d'autoriser le -telnet depuis ou vers l'Internet car il utilise du texte en clair (même pour -le login et le mot de passe !). Si vous voulez avoir un accès au shell de -votre firewall depuis Internet, utilisez SSH :

    -
    - -
    -
    +
    +
    + +
    +

    Si vous ne savez pas quel port ou protocole une application + particulière utilise, regardez ici.

    +
    + +
    +

    Important: Je ne vous recommande pas d'autoriser le + telnet depuis ou vers l'Internet car il utilise du texte en clair (même +pour le login et le mot de passe !). Si vous voulez avoir un accès au shell +de votre firewall depuis Internet, utilisez SSH :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    +
    +
    -
    -
    - -
    + +
    + +
         ACCEPT	net	fw	tcp	22
    -
    - -
    +
    + +

    - A ce point, éditez /etc/shorewall/rules pour rajouter les autres connexions -désirées.

    -
    - -
    + A ce point, éditez /etc/shorewall/rules pour rajouter les autres connexions + désirées.

    +
    + +

    Lancer et Arrêter son Firewall

    -
    - -
    +
    + +

    Arrow - La procédure d'installation configure votre -système pour lancer Shorewall au boot du système, mais au début avec la version -1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall -avec que la configuration soit finie. Une fois que vous en aurez fini avec -la configuration du firewall, vous pouvez permettre le lancement de Shorewall -en supprimant le fichier /etc/shorewall/startup_disabled.
    -

    - -

    IMPORTANT: Les utilisateurs des -paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.
    -

    -
    - -
    -

    Le firewall est activé en utilisant la commande "shorewall -start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le -routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un -firewall qui tourne peut être relancé en utilisant la commande "shorewall -restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration -de Netfilter, utilisez "shorewall clear".

    -
    - -
    -

    ATTENTION: Si vous êtes connecté à votre firewall depuis -Internet, n'essayez pas une commande "shorewall stop" tant que vous n'avez -pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous -êtes connectée) dans /etc/shorewall/routestopped. - De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; -il est plus intéressant de créer une configuration alternative + La procédure d'installation configure votre +système pour lancer Shorewall au boot du système, mais au début avec la version +1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall + avec que la configuration soit finie. Une fois que vous en aurez fini avec + la configuration du firewall, vous pouvez permettre le lancement de Shorewall + en supprimant le fichier /etc/shorewall/startup_disabled.
    +

    + +

    IMPORTANT: Les utilisateurs +des paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.
    +

    +
    + +
    +

    Le firewall est activé en utilisant la commande "shorewall + start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, +le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un + firewall qui tourne peut être relancé en utilisant la commande "shorewall + restart". Si vous voulez enlever toutes traces de Shorewall sur votre +configuration de Netfilter, utilisez "shorewall clear".

    +
    + +
    +

    ATTENTION: Si vous êtes connecté à votre firewall +depuis Internet, n'essayez pas une commande "shorewall stop" tant que vous +n'avez pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle +vous êtes connectée) dans /etc/shorewall/routestopped. + De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; + il est plus intéressant de créer une configuration alternative et de la tester en utilisant la commande "shorewall try".

    -
    - +
    +

    Last updated 12/9/2002 - Tom Eastep

    - -

    Copyright 2002 Thomas -M. Eastep

    -
    -
    -
    -
    -
    -
    -
    + +

    Copyright 2002 Thomas + M. Eastep

    +
    +
    +
    +
    +
    +
    +
    +


    diff --git a/STABLE/documentation/starting_and_stopping_shorewall.htm b/STABLE/documentation/starting_and_stopping_shorewall.htm index 50f99a757..a12a65b9e 100644 --- a/STABLE/documentation/starting_and_stopping_shorewall.htm +++ b/STABLE/documentation/starting_and_stopping_shorewall.htm @@ -1,341 +1,300 @@ - + - + - + - + Starting and Stopping Shorewall - - - + - - - - - + + - - - - - + the Firewall + + + +
    - - + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Starting/Stopping and Monitoring - the Firewall

    - -
    - - - - +

    If you have a permanent internet connection such as DSL or Cable, - I recommend that you start the firewall automatically at boot. -Once you have installed "firewall" in your init.d directory, simply -type "chkconfig --add firewall". This will start the firewall -in run levels 2-5 and stop it in run levels 1 and 6. If you want + I recommend that you start the firewall automatically at boot. + Once you have installed "firewall" in your init.d directory, simply + type "chkconfig --add firewall". This will start the firewall + in run levels 2-5 and stop it in run levels 1 and 6. If you want to configure your firewall differently from this default, you can use the "--level" option in chkconfig (see "man chkconfig") or using your favorite graphical run-level editor.

    - - - - - - - - +

    Important Notes:
    -

    - +

    +
      -
    1. Shorewall startup is disabled by default. Once you have -configured your firewall, you can enable startup by removing the file -/etc/shorewall/startup_disabled. Note: Users of the .deb package must -edit /etc/default/shorewall and set 'startup=1'.
      -
      2. -
    2. If you use dialup, you may want to start the firewall - in your /etc/ppp/ip-up.local script. I recommend just placing - "shorewall restart" in that script.
      3. - +
    3. Shorewall startup is disabled by default. Once you have + configured your firewall, you can enable startup by removing the file + /etc/shorewall/startup_disabled. Note: Users of the .deb package must + edit /etc/default/shorewall and set 'startup=1'.
      +
      4. +
    4. If you use dialup, you may want to start the firewall + in your /etc/ppp/ip-up.local script. I recommend just placing "shorewall + restart" in that script.
      5. +
    - -

    -

    - - - - + +

    +

    You can manually start and stop Shoreline Firewall using the "shorewall" - shell program:

    - - + shell program:

    + - If you include the keyword debug as the first argument, then - a shell trace of the command is produced as in:
    - + If you include the keyword debug as the first argument, +then a shell trace of the command is produced as in:
    + 
    	shorewall debug start 2> /tmp/trace
    - - - - +

    The above command would trace the 'start' command and place the trace information in the file /tmp/trace
    -

    - +

    +

    The Shorewall State Diagram is shown at the - bottom of this page.
    -

    - + bottom of this page.
    +

    +

    The "shorewall" program may also be used to monitor the firewall.

    - - +
      -
    • shorewall status - produce a verbose report about the -firewall (iptables -L -n -v)
      • -
    • shorewall show chain - produce a verbose report - about chain (iptables -L chain -n -v)
      • -
    • shorewall show nat - produce a verbose report about the - nat table (iptables -t nat -L -n -v)
      • -
    • shorewall show tos - produce a verbose report about the - mangle table (iptables -t mangle -L -n -v)
      • -
    • shorewall show log - display the last 20 packet log entries.
      • -
    • shorewall show connections - displays the IP connections - currently being tracked by the firewall.
      • -
    • shorewall - show - tc - displays - information about the traffic control/shaping configuration.
      • -
    • shorewall monitor [ delay ] - Continuously display the - firewall status, last 20 log entries and nat. When the log -entry display changes, an audible alarm is sounded.
      • -
    • shorewall hits - Produces several reports about the Shorewall - packet log messages in the current /var/log/messages file.
      • -
    • shorewall version - Displays the installed version - number.
      • -
    • shorewall check - Performs a cursory validation of the - zones, interfaces, hosts, rules and policy files.
      -
      - The "check" command is totally unsuppored -and does not parse and validate the generated iptables commands. Even -though the "check" command completes successfully, the configuration -may fail to start. Problem reports that complain about errors that the 'check' -command does not detect will not be accepted.
      -
      - See the recommended way to make configuration changes described below.
      -
      -
      • -
    • shorewall try configuration-directory [ timeout - ] - Restart shorewall using the specified configuration and if an - error occurs or if the timeout option is given and the new +
    • shorewall status - produce a verbose report about the + firewall (iptables -L -n -v)
      • +
    • shorewall show chain - produce a verbose report + about chain (iptables -L chain -n -v)
      • +
    • shorewall show nat - produce a verbose report about +the nat table (iptables -t nat -L -n -v)
      • +
    • shorewall show tos - produce a verbose report about +the mangle table (iptables -t mangle -L -n -v)
      • +
    • shorewall show log - display the last 20 packet log +entries.
      • +
    • shorewall show connections - displays the IP connections + currently being tracked by the firewall.
      • +
    • shorewall +show tc - displays + information about the traffic control/shaping configuration.
      • +
    • shorewall monitor [ delay ] - Continuously display +the firewall status, last 20 log entries and nat. When the +log entry display changes, an audible alarm is sounded.
      • +
    • shorewall hits - Produces several reports about the +Shorewall packet log messages in the current /var/log/messages +file.
      • +
    • shorewall version - Displays the installed version + number.
      • +
    • shorewall check - Performs a cursory validation of +the zones, interfaces, hosts, rules and policy files.
      +
      + The "check" command is totally unsuppored + and does not parse and validate the generated iptables commands. +Even though the "check" command completes successfully, the configuration + may fail to start. Problem reports that complain about errors that the 'check' + command does not detect will not be accepted.
      +
      + See the recommended way to make configuration changes described +below.
      +
      +
      • +
    • shorewall try configuration-directory [ timeout + ] - Restart shorewall using the specified configuration and if +an error occurs or if the timeout option is given and the new configuration has been up for that many seconds then shorewall is restarted using the standard configuration.
      • -
    • shorewall deny, shorewall reject, shorewall accept and - shorewall save implement dynamic - blacklisting.
      • -
    • shorewall logwatch (added in version 1.3.2) - Monitors - the LOGFILE and produces an audible alarm when - new Shorewall messages are logged.
      • - +
    • shorewall deny, shorewall reject, shorewall accept +and shorewall save implement dynamic blacklisting.
      • +
    • shorewall logwatch (added in version 1.3.2) - Monitors + the LOGFILE and produces an audible alarm +when new Shorewall messages are logged.
      • +
    - Finally, the "shorewall" program may be used to dynamically alter - the contents of a zone.
    - + Beginning with Shorewall 1.4.6, /sbin/shorewall supports a couple of commands +for dealing with IP addresses and IP address ranges:
    +
      -
    • shorewall add interface[:host] zone - - Adds the specified interface (and host if included) to the specified +
    • shorewall ipcalc [ address mask | address/vlsm ] - displays +the network address, broadcast address, network in CIDR notation and netmask +corresponding to the input[s].
      • +
    • shorewall iprange address1-address2 - Decomposes the specified +range of IP addresses into the equivalent list of network/host addresses. +
      +
      • + +
    + Finally, the "shorewall" program may be used to dynamically alter the + contents of a zone.
    + +
      +
    • shorewall add interface[:host] zone - + Adds the specified interface (and host if included) to the specified zone.
      • -
    • shorewall delete interface[:host] zone - - Deletes the specified interface (and host if included) from the specified - zone.
      • - +
    • shorewall delete interface[:host] zone + - Deletes the specified interface (and host if included) from +the specified zone.
      • +
    - +
    Examples:
    - +
    shorewall add ipsec0:192.0.2.24 vpn1 - -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
    - shorewall delete ipsec0:192.0.2.24 -vpn1 -- deletes the address 192.0.2.24 from interface ipsec0 -from zone vpn1
    -
    -
    - - -

    The shorewall start, shorewall restart, shorewall check, and - shorewall try commands allow you to specify which Shorewall configuration - to use:

    - - -
    - - -

    shorewall [ -c configuration-directory ] {start|restart|check}
    - shorewall try configuration-directory

    + -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
    + shorewall delete ipsec0:192.0.2.24 + vpn1 -- deletes the address 192.0.2.24 from interface ipsec0 + from zone vpn1
    - - + + +

    The shorewall start, shorewall restart, shorewall check, and + shorewall try commands allow you to specify which Shorewall configuration + to use:

    + +
    +

    shorewall [ -c configuration-directory ] {start|restart|check}
    + shorewall try configuration-directory

    +
    +

    If a configuration-directory is specified, each time that Shorewall - is going to use a file in /etc/shorewall it will first look in the -configuration-directory . If the file is present in the configuration-directory, -that file will be used; otherwise, the file in /etc/shorewall will be -used.

    - - - - + is going to use a file in /etc/shorewall it will first look in the + configuration-directory . If the file is present in the configuration-directory, + that file will be used; otherwise, the file in /etc/shorewall will +be used.

    +

    When changing the configuration of a production firewall, I recommend - the following:

    - - - - + the following:

    +
      - -
    • mkdir /etc/test
      • - -
    • cd /etc/test
      • - -
    • <copy any files that you need to change from - /etc/shorewall to . and change them here>
      • -
    • shorewall -c . check
      • -
    • <correct any errors found by check and check again>
      • - - -
    • /sbin/shorewall - try .
      • - +
    • mkdir /etc/test
      • +
    • cd /etc/test
      • +
    • <copy any files that you need to change +from /etc/shorewall to . and change them here>
      • +
    • shorewall -c . check
      • +
    • <correct any errors found by check and check again>
      • +
    • /sbin/shorewall try .
      • +
    - - +

    If the configuration starts but doesn't work, just "shorewall restart" - to restore the old configuration. If the new configuration fails + to restore the old configuration. If the new configuration fails to start, the "try" command will automatically start the old one for you.

    - - - - +

    When the new configuration works then just

    - - - - +
      - -
    • cp * /etc/shorewall
      • - -
    • cd
      • - -
    • rm -rf /etc/test
      • - +
    • cp * /etc/shorewall
      • +
    • cd
      • +
    • rm -rf /etc/test
      • +
    - - - - +

    The Shorewall State Diargram is depicted below.
    -

    - +

    +
    (State Diagram) -
    -
    - +
    +
    +

     
    -

    - You will note that the commands that result in state transitions -use the word "firewall" rather than "shorewall". That is because the actual - transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall - on Debian); /sbin/shorewall runs 'firewall" according to the following table:
    -
    - +

    + You will note that the commands that result in state transitions + use the word "firewall" rather than "shorewall". That is because the +actual transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall + on Debian); /sbin/shorewall runs 'firewall" according to the following +table:
    +
    + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    shorewall start
    -     		firewall start
    -
    shorewall stop
    -     		firewall stop
    -
    shorewall restart
    -     		firewall restart
    -
    shorewall add
    -     		firewall add
    -
    shorewall delete
    -     		firewall delete
    -
    shorewall refresh
    -     		firewall refresh
    -
    shorewall try
    -     		firewall -c <new configuration> restart
    - If unsuccessful then firewall start (standard configuration)
    - If timeout then firewall restart (standard configuration)
    -
    shorewall start
    +     		firewall start
    +
    shorewall stop
    +     		firewall stop
    +
    shorewall restart
    +     		firewall restart
    +
    shorewall add
    +     		firewall add
    +
    shorewall delete
    +     		firewall delete
    +
    shorewall refresh
    +     		firewall refresh
    +
    shorewall try
    +     		firewall -c <new configuration> restart
    + If unsuccessful then firewall start (standard configuration)
    + If timeout then firewall restart (standard configuration)
    +
    -
    - -

    Updated 2/27/2003 - Tom Eastep -

    - - - +
    + +

    Updated 7/6/2003 - Tom Eastep +

    +

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

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

    +
    +

    diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index 486c59c19..67a842ab9 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -1,81 +1,86 @@ - + - + Shorewall Support Guide - + - - - + + + - - - + + + + + +
    - + bgcolor="#3366ff" height="90"> +
    + +

    Shorewall Support Guide -

    -
    - +

    Before Reporting a Problem or Asking a Question
    -

    - There - are a number of sources of Shorewall information. Please try these - before you post. + + + There are a number of sources of Shorewall information. Please + try these before you post. - +

    Site and Mailing List Archive Search

    - -
    + +
    Match: - + + - Format: - + Format: + - Sort by: - + Sort by: + - Include Mailing List Archives: - + -
    - Search:
    -
    -
    - +
    + Search:
    + +
    +

    Problem Reporting Guidelines
    -

    - + +
      -
    • Please remember we only know -what is posted in your message. Do not leave out any information - that appears to be correct, or was mentioned in a previous - post. There have been countless posts by people who were sure - that some part of their configuration was correct when it actually - contained a small error. We tend to be skeptics where detail - is lacking.
      -
      -
      • -
    • Please keep in mind that you're - asking for free technical support. - Any help we offer is an act of generosity, not an obligation. - Try to make it easy for us to help you. Follow good, courteous - practices in writing and formatting your e-mail. Provide details that - we need if you expect good answers. Exact quoting of -error messages, log entries, command output, and other output is better - than a paraphrase or summary.
      -
      -
      • -
    • - 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.
      -
      -
      • -
    • When reporting a problem, ALWAYS - include this information:
      • - +
    • Please remember we only +know what is posted in your message. Do not leave out any +information that appears to be correct, or was mentioned + in a previous post. There have been countless posts by people + who were sure that some part of their configuration was correct + when it actually contained a small error. We tend to be skeptics +where detail is lacking.
      +
      +
      • +
    • Please keep in mind that +you're asking for free technical +support. Any help we offer is an act of generosity, not an obligation. + Try to make it easy for us to help you. Follow good, courteous + practices in writing and formatting your e-mail. Provide details +that we need if you expect good answers. Exact quoting + of error messages, log entries, command output, and other output is +better than a paraphrase or summary.
      +
      +
      • +
    • + 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.
      +
      +
      • +
    • When reporting a problem, + ALWAYS include this information:
      • +
    - +
      - +
        -
      • the exact version of Shorewall - you are running.
        -
        - shorewall - version
        -
        -
        • - +
      • the exact version of Shorewall + you are running.
        +
        + shorewall version
        +
        +
        • +
      - +
        -
      • the exact kernel version you - are running
        -
        - uname - -a
        -
        -
        • - -
      - -
        -
      • the complete, exact output -of
        -
        - ip -addr show
        -
        -
        • - -
      - -
        -
      • the complete, exact output -of
        -
        - ip -route show
        -
        -
        • - -
      - -
        -
      • If your kernel is modularized, - the exact output from
        -
        - lsmod
        -
        • - +
      - -
    - -
      - +
        -
      • If you are having - connection problems of any kind then:
        -
        - 1. /sbin/shorewall reset
        -
        - 2. Try the connection that is failing.
        -
        - 3. /sbin/shorewall status - > /tmp/status.txt
        -
        - 4. Post the /tmp/status.txt file as an attachment.
        -
        -
        • -
      • the exact wording of any the complete, exact output + of
        +
        + ip + addr show
        +
        +
        • + +
      + +
        +
      • the complete, exact output + of
        +
        + ip + route show
        +
        • + +
      + +
        + + +
      + +
    + +
      + +
        +
      • THIS IS +IMPORTANT! If your problem is +that some type of connection to/from or through your firewall isn't working +then please perform the following four steps:
        +
        + 1. /sbin/shorewall reset
        +
        + 2. Try making the connection that is failing.
        +
        + 3. /sbin/shorewall + status > /tmp/status.txt
        +
        + 4. Post the /tmp/status.txt file as an attachment +(you may compress it if you like).
        +
        +
        • +
      • the exact wording of any ping failure responses
        -
        -
        • -
      • If you installed Shorewall using one of the QuickStart - Guides, please indicate which one.
        -
        -
        • -
      • If you are running Shorewall under Mandrake using - the Mandrake installation of Shorewall, please say so.
        -
        -
        • - +
        + +
      • If you installed Shorewall using one of the QuickStart + Guides, please indicate which one.
        +
        +
        • +
      • If you are running Shorewall under Mandrake using + the Mandrake installation of Shorewall, please say so.
        +
        +
        • +
      -
    • As a general matter, please do not edit the diagnostic - information in an attempt to conceal your IP address, - netmask, nameserver addresses, domain name, etc. These aren't - secrets, and concealing them often misleads us (and 80% of the time, - a hacker could derive them anyway from information contained -in the SMTP headers of your post).
      -
      -
      • -
    • Do you see any "Shorewall" messages ("/sbin/shorewall show log") when - you exercise the function that is giving you problems? If -so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces - file.
      -
      -
      • -
    • Please include any of the Shorewall configuration - files (especially the /etc/shorewall/hosts file - if you have modified that file) that you think are - relevant. If you include /etc/shorewall/rules, please include - /etc/shorewall/policy as well (rules are meaningless unless -one also knows the policies).
      -
      -
      • -
    • 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.
      • - +
    • As a general matter, please do not edit the +diagnostic information in an attempt to conceal +your IP address, netmask, nameserver addresses, domain name, +etc. These aren't secrets, and concealing them often misleads us +(and 80% of the time, a hacker could derive them anyway from +information contained in the SMTP headers of your post).
      +
      +
      • +
    • Do you see any "Shorewall" messages + ("/sbin/shorewall show log") + when you exercise the function that is giving you problems? + If so, include the message(s) in your post along with a copy of +your /etc/shorewall/interfaces file.
      +
      +
      • +
    • Please include any of the Shorewall configuration + files (especially the /etc/shorewall/hosts file + if you have modified that file) that you think are + relevant. If you include /etc/shorewall/rules, please include + /etc/shorewall/policy as well (rules are meaningless unless + one also knows the policies).
      +
      +
      • +
    • 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.
      • +
    - +
    The author gratefully acknowleges that the above list was - heavily plagiarized from the excellent LEAF document by Ray - Olszewski found at Ray + Olszewski found at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
    -
    - + +

    When using the mailing list, please post in plain text

    - +
    A growing number of MTAs serving list subscribers are rejecting all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net "for continuous abuse" because it has been my policy to allow HTML in list posts!!
    -
    - I think that blocking all HTML - is a Draconian way to control spam and that the ultimate - losers here are not the spammers but the list subscribers - whose MTAs are bouncing all shorewall.net mail. As one list -subscriber wrote to me privately "These e-mail admin's need - to get a (expletive deleted) life instead of trying to +
    + I think that blocking all +HTML is a Draconian way to control spam and that the ultimate + losers here are not the spammers but the list subscribers + whose MTAs are bouncing all shorewall.net mail. As one list + subscriber wrote to me privately "These e-mail admin's need + to get a (expletive deleted) life instead of trying to rid the planet of HTML based e-mail". Nevertheless, to allow subscribers to receive list posts as must as possible, I have now configured the list server at shorewall.net to strip all HTML from outgoing posts.
    -
    - If you run your own outgoing mail server -and it doesn't have a valid DNS PTR record, your email won't reach the lists -unless/until the postmaster notices that your posts are being rejected. To -avoid this problem, you should configure your MTA to forward posts to shorewall.net -through an MTA that does have a valid PTR record (such as the one -at your ISP).
    -
    +
    + If you run your own outgoing mail server + and it doesn't have a valid DNS PTR record, your email won't reach the +lists unless/until the postmaster notices that your posts are being rejected. +To avoid this problem, you should configure your MTA to forward posts to +shorewall.net through an MTA that does have a valid PTR record (such +as the one at your ISP).
    + +

    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.

    - If you run Shorewall under -MandrakeSoft Multi Network Firewall (MNF) and you have -not purchased an MNF license from MandrakeSoft then you can - post non MNF-specific Shorewall questions to the . + If you run Shorewall under + MandrakeSoft Multi Network Firewall (MNF) and you have + not purchased an MNF license from MandrakeSoft then you can + post non MNF-specific Shorewall questions to the Shorewall users mailing - list. Do not expect to get free MNF support on the list.
    - -

    If you have a question, you may post it on the Shorewall Forum: - DO NOT USE THE FORUM FOR REPORTING PROBLEMS OR -ASKING FOR HELP WITH PROBLEMS.
    -
    - Otherwise, please post your question or problem to the . Do not expect to get free MNF support on the list + +

    Otherwise, please post your question or problem to the Shorewall users mailing - list .

    - + list .

    +

    To Subscribe to the mailing list go to http://lists.shorewall.net/mailman/listinfo/shorewall-users - .
    -

    -
    - + .
    +

    +
    +

    For information on other Shorewall mailing lists, go to http://lists.shorewall.net
    -

    - -

    Last Updated 6/14/2003 - Tom Eastep

    - +

    + +

    Last Updated 7/9/2003 - Tom Eastep

    +

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

    +

    +
    diff --git a/STABLE/documentation/three-interface.htm b/STABLE/documentation/three-interface.htm index dd86feb72..915393aec 100644 --- a/STABLE/documentation/three-interface.htm +++ b/STABLE/documentation/three-interface.htm @@ -1,438 +1,442 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    + id="AutoNumber5" bgcolor="#3366ff" height="90"> +
    +

    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.

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

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

    - +

    -

    - +

    +

    Shorewall requires 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 + (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 - . Configuration notes that are unique to LEAF/Bering are marked with  + . Configuration notes that are unique to LEAF/Bering are marked with (LEAF Logo) -

    - +

    +

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

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

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

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

    - + 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 three-interface sample - has the following policies:

    - -
    + has the following policies:

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

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

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

    - -

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

    - -
      -
    • -

      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:

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

    -
    - -
    -

    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
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Subnet Address:10.10.10.0locnetACCEPT  
    Broadcast Address:10.10.10.255netallDROPinfo 
    CIDR Notation:10.10.10.0/24allallREJECTinfo 
    -
    - -
    -

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

    -
    - -
    + +
    +

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

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

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

    +

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

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

    + +
      +
    • +

      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:

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

    +
    + +
    +

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

    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.

    - + 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 the DMZ computers would be 10.10.11.254 - and the default gateway for the Local computers would be 10.10.10.254.
    -

    - + and the default gateway for the Local computers would be 10.10.10.254.
    +

    +

    -     WARNING: Your ISP  might -assign your external interface an RFC 1918 address. If that address is -in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC -1918 subnet for your local network and if it is in the 10.10.11.0/24 subnet -then you will need to select a different RFC 1918 subnet for your DMZ.
    -

    - +     WARNING: Your ISP  might + assign your external interface an RFC 1918 address. If that address is + in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC + 1918 subnet for your local network and if it is in the 10.10.11.0/24 subnet + then you will need to select a different RFC 1918 subnet for your DMZ.
    +

    +

    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 + 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 @@ -442,369 +446,82 @@ 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. -

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

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

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

    - +     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
      -
      • - +
    • NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
      • +
    • 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.

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

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

      -
      • - -
    - -
    -

    If you run the name server on the firewall: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    -

    -
    - -
    -
    -

    Run name server on DMZ computer 1

    - + is:

    + +
    - + @@ -814,192 +531,31 @@ the rules in /etc/shorewall/rules.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTION SOURCE DESTINATION ORIGINAL 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
    ACCEPTfwDNAT netudp53  
    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.

    -
    - -
    -

    The sample also includes:

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

    -
    - -
    -
    - - - - - - - - - - - - - - - + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone>dmz:<server local ip address> [:<server + port>] <protocol> <port>    
    -
    - -
    -

    Example - You want to run a publicly-available DNS server - on your firewall system:

    -
    - -
    -
    + +

    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:

    + +
    - + @@ -1009,90 +565,46 @@ allowing all connections from the firewall to the internet.

    - + - + - - + + - - - - - - - - - -
    ACTION SOURCE DESTINATION ORIGINAL ADDRESS
    ACCEPTDNAT netfwdmz:10.10.11.2 tcp53#Allow DNS access80# Forward port 80 from the internet
    ACCEPTnetfwudp
    -     		53#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:

    -
    - -
    -
    - - - - - - - - - - - - - - - + + - - - + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwlocdmz:10.10.11.2 tcp22  80#Allow connections from the local network
    -
    - -
    -

    - -

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible - with Jacques's Shorewall configuration.
    -

    - -
    -
    + +

    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).
      • + +
    + +
    - + @@ -1102,97 +614,591 @@ allowing all connections from the firewall to the internet.

    - + + + + + + + + + + +
    ACTION SOURCE DESTINATION ORIGINAL ADDRESS
    ACCEPTDNATnetdmz: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
    DNAT loc
    -     		fwudp
    -     		53
    -     		#Allow DNS Cache towork
    -     		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.

      +
      • + +
    + +
    +

    If you run the name server on the firewall: + + + + + + + + + + + - - - + + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT loc fw tcp80#Allow weblet to work
    -     		53  
    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  
    +
    +
    + +
    +

    Other Connections

    +
    + +
    +

    The three-interface sample includes the following rules:

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

    +
    + +
    +

    The sample also includes:

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

    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    +
    +
    + +
    +

    Example - You want to run a publicly-available DNS server + on your firewall system:

    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwudp
    +     		53#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:

    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    +
    +
    + +
    +

    + +

    (LEAF Logo) +     Bering users will want to add the following two rules to be compatible + with Jacques's Shorewall configuration.
    +

    + +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    +     		fwudp
    +     		53
    +     		#Allow DNS Cache towork
    +
    ACCEPTlocfwtcp80#Allow weblet to work
    +
    +
    +
    +

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

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

    -
    - -
    +     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 /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 5/19/2003 - + +

    Last updated 6/27/2003 - Tom Eastep

    - +

    Copyright 2002, 2003 - Thomas M. Eastep
    -

    + Thomas M. Eastep
    +

    +
    diff --git a/STABLE/documentation/three-interface_fr.html b/STABLE/documentation/three-interface_fr.html index 8571ef63f..4a0d35712 100755 --- a/STABLE/documentation/three-interface_fr.html +++ b/STABLE/documentation/three-interface_fr.html @@ -1,1194 +1,1197 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    + id="AutoNumber5" bgcolor="#3366ff" height="90"> +

    Three-Interface Firewall

    -
    - +

    Version 2.0.1 Française

    - +

    Notes du traducteur :
    - Je ne prétends pas être un vrai traducteur dans le sens ou mon travail - n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à une - traduction exacte du texte, mais plutôt à en faire une version française -intelligible par tous (et par moi). Les termes techniques sont la plupart -du temps conservés sous leur forme originale et mis entre parenthèses car -vous pouvez les retrouver dans le reste des documentations ainsi que dans -les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer -ce document VETSEL Patrice -(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à + Je ne prétends pas être un vrai traducteur dans le sens ou mon travail + n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à une + traduction exacte du texte, mais plutôt à en faire une version française +intelligible par tous (et par moi). Les termes techniques sont la plupart +du temps conservés sous leur forme originale et mis entre parenthèses car +vous pouvez les retrouver dans le reste des documentations ainsi que dans +les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer +ce document VETSEL Patrice +(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour son formidable outil et sa disponibilité).

    - +


    - Mettre en place un système linux en tant que firewall pour un petit réseau - contenant une DMZ est une chose assez simple à réaliser si vous comprenez - les bases et suivez cette documentation.

    - -

    Ce guide ne prétend pas vous mettre au courant de toutes les possibilités - de Shorewall. Il se focalise sur les besoins pour configurer Shorewall dans - une de ses utilisations les plus populaire :

    - + Mettre en place un système linux en tant que firewall pour un petit +réseau contenant une DMZ est une chose assez simple à réaliser si vous +comprenez les bases et suivez cette documentation.

    + +

    Ce guide ne prétend pas vous mettre au courant de toutes les possibilités + de Shorewall. Il se focalise sur les besoins pour configurer Shorewall +dans une de ses utilisations les plus populaire :

    +
      -
    • Un système Linux utilisé en tant que firewall/routeur pour un petit - réseau local.
      • -
    • Une seule adresse IP publique.
      • -
    • Une DMZ connectée sur une interface Ethernet séparée.
      • -
    • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame Relay, - RTC, ...
      • - +
    • Un système Linux utilisé en tant que firewall/routeur pour un +petit réseau local.
      • +
    • Une seule adresse IP publique.
      • +
    • Une DMZ connectée sur une interface Ethernet séparée.
      • +
    • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame +Relay, RTC, ...
      • +
    - +

    Voici le schéma d'une installation typique.

    - +

    -

    - -

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. Vous -pouvez voir si le paquet est installé en vérifiant la présence du programme - ip sur votre système de firewall. Sous root, utilisez la commande 'which' - pour rechercher le programme :

    - +

    + +

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. +Vous pouvez voir si le paquet est installé en vérifiant la présence du programme + ip sur votre système de firewall. Sous root, utilisez la commande 'which' + pour rechercher le programme :

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

    Je vous recommande dans un premier temps de parcourir tout le guide pour - vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant - le changements dans votre configuration. Les points où, les changements dans - la configuration sont recommandées, sont signalés par une Je vous recommande dans un premier temps de parcourir tout le guide pour + vous familiariser avec ce qu'il va se passer, et de revenir au début en +effectuant le changements dans votre configuration. Les points où, les changements +dans la configuration sont recommandées, sont signalés par une -

    - +

    +

    - Si vous éditez vos fichiers de configuration sur un système Windows, -vous devez les sauver comme des fichiers Unix si votre éditeur offre cette -option sinon vous devez les faire passer par dos2unix avant d'essayer de -les utiliser. De la même manière, si vous copiez un fichier de configuration -depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix + Si vous éditez vos fichiers de configuration sur un système Windows, +vous devez les sauver comme des fichiers Unix si votre éditeur offre cette +option sinon vous devez les faire passer par dos2unix avant d'essayer de +les utiliser. De la même manière, si vous copiez un fichier de configuration +depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser avec Shorewall.

    - + - +

    Les Concepts de Shorewall

    - +

    - Les fichiers de configuration pour Shorewall sont situés dans le répertoire - /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec - quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez la configuration - d'exemple three-interface - sample, un-tarez la (tar -zxvf three-interfaces.tgz) et copiez - les fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même -nom déjà existant dans /etc/shorewall installés lors de l'installation de -Shorewall).

    - -

    En même temps que chacun des fichiers est présenté, je vous suggère de - jeter un oeil à ceux qui se trouvent réellement sur votre système -- chacun - des fichiers contient des instructions de configuration détaillées et des - entrées par défaut.

    - -

    Shorewall voit le réseau où il tourne comme composé par un ensemble de - zones. Dans les fichiers de configuration fournis pour trois interfaces, - trois zones sont définies :

    - + Les fichiers de configuration pour Shorewall sont situés dans le répertoire + /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec + quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez la configuration + d'exemple three-interface + sample, un-tarez la (tar -zxvf three-interfaces.tgz) et copiez + les fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même + nom déjà existant dans /etc/shorewall installés lors de l'installation de + Shorewall).

    + +

    En même temps que chacun des fichiers est présenté, je vous suggère de + jeter un oeil à ceux qui se trouvent réellement sur votre système -- chacun + des fichiers contient des instructions de configuration détaillées et des + entrées par défaut.

    + +

    Shorewall voit le réseau où il tourne comme composé par un ensemble de + zones. Dans les fichiers de configuration fournis pour trois interfaces, + trois zones sont définies :

    + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    NameDescription
    netThe Internet
    locVotre réseau local
    dmzZone Demilitarisée
    NameDescription
    netThe Internet
    locVotre réseau local
    dmzZone Demilitarisée
    - +

    Les noms de zone sont définis dans /etc/shorewall/zones.

    - -

    Shorewall reconnaît aussi le système de firewall comme sa propre zone - -par défaut, le firewall lui même est connu en tant que fw.

    - -

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées - en utilisant les termes de zones.

    - + +

    Shorewall reconnaît aussi le système de firewall comme sa propre zone +- par défaut, le firewall lui même est connu en tant que fw.

    + +

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées + en utilisant les termes de zones.

    +
      -
    • Vous exprimez les politiques par défaut pour les connexions d'une - zone à une autre dans le fichier /etc/shorewall/policy - .
      • -
    • Vous définissez les exceptions à ces règles de politiques par défaut - dans le fichier /etc/shorewall/rules.
      • - +
    • Vous exprimez les politiques par défaut pour les connexions d'une + zone à une autre dans le fichier /etc/shorewall/policy + .
      • +
    • Vous définissez les exceptions à ces règles de politiques par +défaut dans le fichier /etc/shorewall/rules.
      • +
    - -

    Pour chacune des demandes de connexion entrantes dans le firewall, les - demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. - Si aucune des règles dans ce fichier ne correspondent, alors la première -politique dans /etc/shorewall/policy qui y correspond est appliquée. Si cette -politique est REJECT ou DROP la requête est alors comparée par rapport aux -règles contenues dans /etc/shorewall/common (l'archive d'exemple vous fournit -ce fichier).

    - -

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive three-interface - sample a les politiques suivantes :

    - -
    + +

    Pour chacune des demandes de connexion entrantes dans le firewall, les + demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. + Si aucune des règles dans ce fichier ne correspondent, alors la première + politique dans /etc/shorewall/policy qui y correspond est appliquée. Si +cette politique est REJECT ou DROP la requête est alors comparée par rapport +aux règles contenues dans /etc/shorewall/common (l'archive d'exemple vous +fournit ce fichier).

    + +

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive three-interface + sample a les politiques suivantes :

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

    Dans l'archive three-interface, la ligne suivante est existante mais - elle est commentée. Si vous souhaitez que votre système de firewall puisse - avoir un accès complet aux serveurs sur Internet, décommentez la.

    - +
    + +
    +

    Dans l'archive three-interface, la ligne suivante est existante mais + elle est commentée. Si vous souhaitez que votre système de firewall puisse + avoir un accès complet aux serveurs sur Internet, décommentez la.

    + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT
    -
    -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT
    +
    +
    -
    - +
    +

    Les politiques précédentes vont :

    - +
      -
    1. permettre toutes demandes de connexion depuis le firewall vers +
    2. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      3. -
    3. drop (ignorer) toutes les demandes de connexion depuis l'Internet +
    4. drop (ignorer) toutes les demandes de connexion depuis l'Internet vers votre firewall ou vers votre réseau local
      5. -
    5. Facultativement accepter toutes les demandes de connexion depuis +
    6. Facultativement accepter toutes les demandes de connexion depuis votre firewall et vers Internet (si vous decommentez la politique précédente)
      7. -
    7. reject (rejeter) toutes les autres demandes de connexion.
      8. - +
    8. reject (rejeter) toutes les autres demandes de connexion.
      9. +
    - +

    - A ce point, éditez votre /etc/shorewall/policy et faites y les changements - que vous désire

    - + A ce point, éditez votre /etc/shorewall/policy et faites y les changements + que vous désire

    +

    Les Interfaces Réseau

    - +

    -

    - -

    Le firewall a trois interfaces de réseau. Lorsque la connexion - Internet passe par le câble ou par un ROUTEUR (pas un simple modem) ADSL -(non USB), l'interface vers l'extérieur (External Interface) sera l'adaptateur - sur lequel est connecté le routeur (e.g., eth0) à moins que vous ne vous - connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling - Protocol (PPTP), dans ce cas l'interface extérieure sera une interface de - type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), -votre interface extérieure sera aussi ppp0. Si votre connexion passe par Numéris -(ISDN), votre interface extérieure sera ippp0.

    - +

    + +

    Le firewall a trois interfaces de réseau. Lorsque la connexion + Internet passe par le câble ou par un ROUTEUR (pas un simple modem) ADSL + (non USB), l'interface vers l'extérieur (External Interface) sera l'adaptateur + sur lequel est connecté le routeur (e.g., eth0) à moins que vous ne vous + connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling + Protocol (PPTP), dans ce cas l'interface extérieure sera une interface +de type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), + votre interface extérieure sera aussi ppp0. Si votre connexion passe par +Numéris (ISDN), votre interface extérieure sera ippp0.

    +

    - Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez - CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

    - -

    Votre Interface locale sera un adaptateur Ethernet - (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs - locaux seront connectés à ce même switch (note : si vous n'avez qu'un seul - ordinateur en local, vous pouvez le connecter directement au firewall par - un câble croisé).

    - -

    Votre interface DMZ sera aussi un adaptateur Ethernet - (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs - appartenant à la DMZ seront connectés à ce même switch (note : si vous n'avez - qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement au - firewall par un câble croisé).

    - + Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez + CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

    + +

    Votre Interface locale sera un adaptateur Ethernet + (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos +ordinateurs locaux seront connectés à ce même switch (note : si vous n'avez +qu'un seul ordinateur en local, vous pouvez le connecter directement au +firewall par un câble croisé).

    + +

    Votre interface DMZ sera aussi un adaptateur Ethernet + (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs + appartenant à la DMZ seront connectés à ce même switch (note : si vous +n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement +au firewall par un câble croisé).

    +

    - Ne connectez pas l'interface interne et externe sur le même hub - ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas que - ce soit shorewall qui ne marche pas.

    - + Ne connectez pas l'interface interne et externe sur le même +hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez +pas que ce soit shorewall qui ne marche pas.

    +

    - L'exemple de configuration de Shorewall pour trois interfaces suppose -que l'interface externe est eth0, l'interface locale est eth1 -et que la DMZ est sur l'interface eth2. Si votre configuration diffère, - vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. - Tant que vous y êtes, vous pourriez parcourir la liste des options qui sont - spécifiées pour les interfaces. Quelques trucs :

    - + L'exemple de configuration de Shorewall pour trois interfaces suppose + que l'interface externe est eth0, l'interface locale est eth1 + et que la DMZ est sur l'interface eth2. Si votre configuration +diffère, vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces +en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste des +options qui sont spécifiées pour les interfaces. Quelques trucs :

    +
      -
    • -

      Si votre interface externe est ppp0 ou ippp0, vous pouvez - remplacer le "detect" dans la seconde colonne par un "-".

      -
      • -
    • -

      Si votre interface externe est ppp0 ou ippp0 ou bien si -vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la liste -d'option.

      -
      • - +
    • +

      Si votre interface externe est ppp0 ou ippp0, vous pouvez + remplacer le "detect" dans la seconde colonne par un "-".

      +
      • +
    • +

      Si votre interface externe est ppp0 ou ippp0 ou bien +si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la +liste d'option.

      +
      • +
    - +

    Adresses IP

    - -

    Avant d'aller plus loin, nous devons dire quelques mots au - sujet du Protocole d'adresse Internet (IP). Normalement, votre fournisseur - Internet (ISP) vous assignera une seule adresse IP (single Public IP address). - Cette adresse peut être assignée par le Dynamic Host Configuration Protocol - (DHCP) ou lors de l'établissement de votre connexion lorsque vous vous connectez - (modem standard) ou établissez votre connexion PPP. Dans de rares cas , votre - provider peu vous assigner une adresse statique (staticIP address); cela -signifie que vous configurez votre interface externe sur votre firewall afin -d'utiliser cette adresse de manière permanente. Une fois votre adresse externe -assignée, elle va être partagée par tout vos systèmes lors de l'accès à Internet. -Vous devrez assigner vos propres adresses à votre réseau local (votre interface - interne sur le firewall ainsi que les autres ordinateurs). La RFC 1918 -réserve plusieurs plages d'IP (Private IP address ranges) à cette fin :

    - -
    + +

    Avant d'aller plus loin, nous devons dire quelques mots au + sujet du Protocole d'adresse Internet (IP). Normalement, votre fournisseur + Internet (ISP) vous assignera une seule adresse IP (single Public IP address). + Cette adresse peut être assignée par le Dynamic Host Configuration Protocol + (DHCP) ou lors de l'établissement de votre connexion lorsque vous vous +connectez (modem standard) ou établissez votre connexion PPP. Dans de rares +cas , votre provider peu vous assigner une adresse statique (staticIP address); +cela signifie que vous configurez votre interface externe sur votre firewall +afin d'utiliser cette adresse de manière permanente. Une fois votre adresse +externe assignée, elle va être partagée par tout vos systèmes lors de l'accès +à Internet. Vous devrez assigner vos propres adresses à votre réseau local +(votre interface interne sur le firewall ainsi que les autres ordinateurs). +La RFC 1918 réserve plusieurs plages d'IP (Private IP address ranges) à +cette fin :

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

    - Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface - externe et si elle est comprise dans une des plages précédentes, vous devriez - enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    -
    - -
    -

    Vous devrez assigner les adresses locales à un sous-réseau - (sub-network ou subnet) et les adresse pour la DMZ à un autre - sous-réseau. Pour ce faire, nous pouvons considérer qu'un sous-réseau consiste - en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera - une masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0 est - réservée comme l'adresse du sous-réseau (Subnet Address) et x.y.z.255 - est réservée en tant qu'adresse de broadcast du sous-réseau (Subnet Broadcast - Address). Sous Shorewall, un sous-réseau est décrit/désigné en utilisant - la notation Classless InterDomain - Routing(CIDR) qui consiste en l'adresse du sous-réseau suivie par - "/24". Le "24" se réfère au nombre de bits "1" consécutifs dans la partie - gauche du masque de sous-réseau.

    -
    - -
    + Avant de lancer Shorewall, vous devriez regarder l'adresse de votre +interface externe et si elle est comprise dans une des plages précédentes, +vous devriez enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    +
    + +
    +

    Vous devrez assigner les adresses locales à un sous-réseau + (sub-network ou subnet) et les adresse pour la DMZ à un autre + sous-réseau. Pour ce faire, nous pouvons considérer qu'un sous-réseau consiste + en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera + une masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0 +est réservée comme l'adresse du sous-réseau (Subnet Address) +et x.y.z.255 est réservée en tant qu'adresse de broadcast du sous-réseau +(Subnet Broadcast Address). Sous Shorewall, un sous-réseau +est décrit/désigné en utilisant la notation Classless InterDomain Routing(CIDR) +qui consiste en l'adresse du sous-réseau suivie par "/24". Le "24" se réfère +au nombre de bits "1" consécutifs dans la partie gauche du masque de sous-réseau. +

    +
    + +

    Exemple de sous-réseau (subnet) :

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

    Il est de convention d'assigner à l'interface interne la première -adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple précédent) - ou la dernière utilisable (10.10.10.254).

    -
    - -
    -

    L'un des buts d'un sous-réseau est de permettre à tous les - ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs ils - peuvent communiquer directement. Pour communiquer avec des systèmes en dehors - du sous-réseau, les ordinateurs envoient des paquets à travers le gateway - (routeur).

    -
    - -
    + +
    + +
    +

    Il est de convention d'assigner à l'interface interne la +première adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple +précédent) ou la dernière utilisable (10.10.10.254).

    +
    + +
    +

    L'un des buts d'un sous-réseau est de permettre à tous les + ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs +ils peuvent communiquer directement. Pour communiquer avec des systèmes +en dehors du sous-réseau, les ordinateurs envoient des paquets à travers +le gateway (routeur).

    +
    + +

    - Vos ordinateurs locaux (ordinateur local 1 et 2) devraient être configurés - avec leur passerelle par défaut (default gateway)pointant sur l'adresse - IP de l'interface interne du firewall, et les ordinateurs de la DMZ devraient - être configurés avec leur passerelle par défaut (default gateway) -pointant sur l'adresse IP de l'interface DMZ du firewall.

    -
    - -

    Cette courte description ne fait que survoler les concepts - de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur l'adressage - IP et le routage, je vous recommande chaudement "IP Fundamentals: -What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    - -

    Pour rappel, ce guide supposera que vous avez configuré votre - réseau comme montrer ci-dessous :

    - + Vos ordinateurs locaux (ordinateur local 1 et 2) devraient être configurés + avec leur passerelle par défaut (default gateway)pointant sur l'adresse + IP de l'interface interne du firewall, et les ordinateurs de la DMZ devraient + être configurés avec leur passerelle par défaut (default gateway) + pointant sur l'adresse IP de l'interface DMZ du firewall.

    +
    + +

    Cette courte description ne fait que survoler les concepts + de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur +l'adressage IP et le routage, je vous recommande chaudement "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", Thomas + A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    + +

    Pour rappel, ce guide supposera que vous avez configuré votre + réseau comme montrer ci-dessous :

    +

    -

    - -

    La passerelle par défaut (default gateway) pour les ordinateurs - de la DMZ sera 10.10.11.254 et le passerelle par défaut pour les ordinateurs - en local sera 10.10.10.254.

    - +

    + +

    La passerelle par défaut (default gateway) pour les ordinateurs + de la DMZ sera 10.10.11.254 et le passerelle par défaut pour les +ordinateurs en local sera 10.10.10.254.

    +

    IP Masquerading (SNAT)

    - -

    Les adresses réservées par la RFC 1918 sont parfois désignées - comme non-routables car les routeurs Internet (backbone) ne font pas circuler - les paquets qui ont une adresse de destination appartenant à la RFC-1918. - Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une -connexion à un serveur par Internet, le firewall doit appliquer un NAT (Network -Address Translation). Le firewall ré écrit l'adresse source dans le paquet, -et l'a remplace par l'adresse de l'interface externe du firewall; en d'autres -mots, le firewall fait croire que c'est lui même qui initie la connexion. -Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer -les paquets au firewall (souvenez vous que les paquets qui ont pour adresse -de destination, une adresse réservée par la RFC 1918 ne pourront pas être -routés à travers Internet, donc l'hôte Internet ne pourra adresser sa réponse -à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il remet - l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur - 1.

    - -

    Sur les systèmes Linux, ce procédé est souvent appelé de l'IP -Masquerading mais vous verrez aussi le terme de Source Network Address Translation -(SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter :

    - + +

    Les adresses réservées par la RFC 1918 sont parfois désignées + comme non-routables car les routeurs Internet (backbone) ne font pas circuler + les paquets qui ont une adresse de destination appartenant à la RFC-1918. + Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une + connexion à un serveur par Internet, le firewall doit appliquer un NAT (Network + Address Translation). Le firewall ré écrit l'adresse source dans le paquet, + et l'a remplace par l'adresse de l'interface externe du firewall; en d'autres + mots, le firewall fait croire que c'est lui même qui initie la connexion. + Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer + les paquets au firewall (souvenez vous que les paquets qui ont pour adresse + de destination, une adresse réservée par la RFC 1918 ne pourront pas être + routés à travers Internet, donc l'hôte Internet ne pourra adresser sa réponse + à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il remet + l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur + 1.

    + +

    Sur les systèmes Linux, ce procédé est souvent appelé de +l'IP Masquerading mais vous verrez aussi le terme de Source Network Address +Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter +:

    +
      -
    • -

      Masquerade désigne le cas ou vous laissez votre firewall - détecter automatiquement l'adresse de l'interface externe.

      -
      • -
    • -

      SNAT désigne le cas où vous spécifiez explicitement l'adresse - source des paquets sortant de votre réseau local.

      -
      • - +
    • +

      Masquerade désigne le cas ou vous laissez votre firewall + détecter automatiquement l'adresse de l'interface externe.

      +
      • +
    • +

      SNAT désigne le cas où vous spécifiez explicitement l'adresse + source des paquets sortant de votre réseau local.

      +
      • +
    - -

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré - avec des entrés dans le fichier /etc/shorewall/masq.

    - + +

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré + avec des entrés dans le fichier /etc/shorewall/masq.

    +

    - Si votre interface externe est eth0, votre interface locale eth1 - et votre interface pour la DMZ eth2 vous n'avez pas besoin de modifier - le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq - et changez le en conséquence.

    - + Si votre interface externe est eth0, votre interface locale eth1 + et votre interface pour la DMZ eth2 vous n'avez pas besoin de modifier + le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq + et changez le en conséquence.

    +

    - Si votre IP externe est statique, vous pouvez la mettre dans la troisième - colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre - firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de - mettre votre IP statique dans la troisième colonne permet un traitement des - paquets sortant un peu plus efficace.
    -

    - + Si votre IP externe est statique, vous pouvez la mettre dans la troisième + colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre + firewall fonctionnera bien si vous laissez cette colonne vide. Le fait +de mettre votre IP statique dans la troisième colonne permet un traitement +des paquets sortant un peu plus efficace.
    +

    +

    - Si vous utilisez les paquets Debian, vérifiez que votre fichier de configuration - shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas - faite les changements nécessaires :
    -

    - + Si vous utilisez les paquets Debian, vérifiez que votre fichier de configuration + shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas + faite les changements nécessaires :
    +

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

    Port Forwarding (DNAT)

    - -

    Un de nos buts est de, peut être, faire tourner un ou plusieurs - serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse - RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter - directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes - de connexion au firewall qui ré écrit l'adresse de destination de votre serveur, - et fait passer le paquet à celui-ci. Lorsque votre serveur répond, le firewall - applique automatiquement un SNAT pour ré écrire l'adresse source dans la -réponse.

    - -

    Ce procédé est appelé Port Forwarding ou Destination Network - Address Translation(DNAT). Vous configurez le port forwarding en utilisant - les règles DNAT dans le fichier /etc/shorewall/rules.

    - -

    La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules - est :

    - -
    + +

    Un de nos buts est de, peut être, faire tourner un ou plusieurs + serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse + RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter + directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes + de connexion au firewall qui ré écrit l'adresse de destination de votre +serveur, et fait passer le paquet à celui-ci. Lorsque votre serveur répond, +le firewall applique automatiquement un SNAT pour ré écrire l'adresse source +dans la réponse.

    + +

    Ce procédé est appelé Port Forwarding ou Destination Network + Address Translation(DNAT). Vous configurez le port forwarding en utilisant + les règles DNAT dans le fichier /etc/shorewall/rules.

    + +

    La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules + est :

    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server -port>]<protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server + port>]<protocol><port>
    +
    +
    -
    - -

    Si vous ne spécifiez pas le <server port>, il est supposé - être le même que <port>.

    - -

    Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et vous - voulez faire passer les paquets entrant en TCP sur le port 80 à ce système - :

    - -
    +
    + +

    Si vous ne spécifiez pas le <server port>, il est supposé + être le même que <port>.

    + +

    Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et vous + voulez faire passer les paquets entrant en TCP sur le port 80 à ce système + :

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
    ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
    ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
    -
    - +
    +

    Deux points importants à garder en mémoire :

    - +
      -
    • Lorsque vous vous connectez à votre serveur à partir de votre réseau - local, vous devez utiliser l'adresse IP interne du serveur (10.10.11.2).
      • -
    • Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes - de connexion entrantes sur le port 80. Si vous avez des problèmes pour vous - connecter à votre serveur web, essayez la règle suivante et connectez vous - sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est votre -IP externe).
      • - +
    • Lorsque vous vous connectez à votre serveur à partir de votre +réseau local, vous devez utiliser l'adresse IP interne du serveur (10.10.11.2).
      • +
    • Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes + de connexion entrantes sur le port 80. Si vous avez des problèmes pour +vous connecter à votre serveur web, essayez la règle suivante et connectez +vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est votre + IP externe).
      • +
    - -
    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000
    +
    +
    -
    - -

    Si vous voulez avoir la possibilité de vous connecter à votre serveur depuis -le réseau local en utilisant votre adresse externe, et si vous avez une adresse -IP externe statique (fixe), vous pouvez remplacer la règle loc->dmz précédente -par :

    - -
    +
    + +

    Si vous voulez avoir la possibilité de vous connecter à votre serveur +depuis le réseau local en utilisant votre adresse externe, et si vous avez +une adresse IP externe statique (fixe), vous pouvez remplacer la règle loc->dmz +précédente par :

    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    -
    - -

    Si vous avez une IP dynamique, alors vous devez vous assurer que votre - interface externe est en route avant de lancer Shorewall et vous devez suivre - les étapes suivantes (en supposant que votre interface externe est eth0) - :

    - +
    + +

    Si vous avez une IP dynamique, alors vous devez vous assurer que votre + interface externe est en route avant de lancer Shorewall et vous devez +suivre les étapes suivantes (en supposant que votre interface externe est +eth0) :

    +
      -
    1. Insérez ce qui suit dans /etc/shorewall/params :
      -
      - ETH0_IP=`find_interface_address eth0`
      -
      2. -
    2. Faites votre règle loc->dmz :
      3. - +
    3. Insérez ce qui suit dans /etc/shorewall/params :
      +
      + ETH0_IP=`find_interface_address eth0`
      +
      4. +
    4. Faites votre règle loc->dmz :
      5. +
    - -
    + +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    -     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    +     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    -
    - -

    Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre adresse -IP externe, regardez FAQ 2a.

    - +
    + +

    Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre +adresse IP externe, regardez FAQ 2a.

    +

    - A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

    - + A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

    +

    Domain Name Server (DNS)

    - -

    Normalement, quand vous vous connectez à votre fournisseur - (ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le -firewall (Domain Name Service) est configuré automatiquement (c.a.d., le fichier -/etc/resolv.conf a été écrit). Il arrive que votre provider vous donne une -paire d'adresse IP pour les DNS (name servers) afin que vous configuriez manuellement -votre serveur de nom primaire et secondaire. La manière dont le DNS est configuré -sur votre firewall est de votre responsabilité. Vous pouvez procéder d'une -de ses deux façons :

    - + +

    Normalement, quand vous vous connectez à votre fournisseur + (ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le + firewall (Domain Name Service) est configuré automatiquement (c.a.d., le +fichier /etc/resolv.conf a été écrit). Il arrive que votre provider vous +donne une paire d'adresse IP pour les DNS (name servers) afin que vous configuriez +manuellement votre serveur de nom primaire et secondaire. La manière dont +le DNS est configuré sur votre firewall est de votre responsabilité. Vous +pouvez procéder d'une de ses deux façons :

    +
      -
    • -

      Vous pouvez configurer votre système interne pour utiliser - les noms de serveurs de votre provider. Si votre fournisseur vous donne les - adresses de leurs serveurs ou si ces adresses sont disponibles sur leur site - web, vous pouvez configurer votre système interne afin de les utiliser. Si - cette information n'est pas disponible, regardez dans /etc/resolv.conf sur - votre firewall -- les noms des serveurs sont donnés dans l'enregistrement - "nameserver" dans ce fichier.

      -
      • -
    • +
    • +

      Vous pouvez configurer votre système interne pour utiliser + les noms de serveurs de votre provider. Si votre fournisseur vous donne +les adresses de leurs serveurs ou si ces adresses sont disponibles sur leur +site web, vous pouvez configurer votre système interne afin de les utiliser. +Si cette information n'est pas disponible, regardez dans /etc/resolv.conf +sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement + "nameserver" dans ce fichier.

      +
      • +

    • - Vous pouvez installer/configurer un cache dns (Caching Name Server) sur - votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre en cache - un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs - de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez - votre système interne pour utiliser le firewall lui même comme étant le seul - serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne du firewall - (10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom si vous décidez - de faire tourner le serveur de nom sur votre firewall. Pour permettre à -vos systèmes locaux de discuter avec votre serveur cache de nom, vous devez -ouvrir le port 53 (UDP ET  TCP) sur le firewall vers le réseau local; vous -ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules. -

      -
      • - + Vous pouvez installer/configurer un cache dns (Caching Name Server) +sur votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre +en cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour +les utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette +approche, vous configurez votre système interne pour utiliser le firewall +lui même comme étant le seul serveur de nom primaire. Vous pouvez utiliser +l'adresse IP interne du firewall (10.10.10.254 dans l'exemple) pour l'adresse +de serveur de nom si vous décidez de faire tourner le serveur de nom sur +votre firewall. Pour permettre à vos systèmes locaux de discuter avec votre +serveur cache de nom, vous devez ouvrir le port 53 (UDP ET  TCP) sur le +firewall vers le réseau local; vous ferez ceci en ajoutant les règles suivantes +dans /etc/shorewall/rules.

      + +
    - -
    -

    Si vous faites tourner le serveur de nom sur le firewall - : + +

    +

    Si vous faites tourner le serveur de nom sur le firewall + : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53
    -
    -
    ACCEPTlocfwudp53
    -
    -
    ACCEPTdmzfwtcp53
    -
    -
    ACCEPTdmzfwudp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53
    +
    +
    ACCEPTlocfwudp53
    +
    +
    ACCEPTdmzfwtcp53
    +
    +
    ACCEPTdmzfwudp53
    +
    +
    -

    -
    - -
    -
    +

    +
    + +
    +

    Le serveur de nom tourne sur l'ordinateur 1 de la DMZ

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

    Autres Connexions

    -
    - -
    -

    L'exemple pour trois interfaces contient les règles suivantes - :

    -
    - -
    -
    +
    + +
    +

    L'exemple pour trois interfaces contient les règles suivantes + :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53
    -
    -
    ACCEPTfwnettcp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53
    +
    +
    ACCEPTfwnettcp53
    +
    +
    -
    -
    - -
    -

    Ces règles permettent l'accès DNS depuis votre firewall et - peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy - autorisant toutes les connexions depuis votre firewall et vers Internet.

    -
    - -
    + +
    + +
    +

    Ces règles permettent l'accès DNS depuis votre firewall et + peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy + autorisant toutes les connexions depuis votre firewall et vers Internet.

    +
    + +

    L'exemple contient aussi :

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22
    -
    -
    ACCEPTlocdmztcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22
    +
    +
    ACCEPTlocdmztcp22
    +
    +
    -
    -
    - -
    -

    Cette règle permet de faire fonctionner une serveur SSH sur - le firewall et sur tous les systèmes de la DMZ et d'y autoriser la connexion - à partir de votre réseau local.

    -
    - -
    -

    Si vous désirez permettre d'autres connexions entre vos systèmes, - la forme générale est :

    -
    - -
    -
    +
    +
    + +
    +

    Cette règle permet de faire fonctionner une serveur SSH sur + le firewall et sur tous les systèmes de la DMZ et d'y autoriser la connexion + à partir de votre réseau local.

    +
    + +
    +

    Si vous désirez permettre d'autres connexions entre vos systèmes, + la forme générale est :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>
    +
    +
    -
    -
    - -
    -

    Exemple - Vous voulez faire tourner un serveur DNS disponible - pour le publique sur votre firewall :

    -
    - -
    -
    +
    +
    + +
    +

    Exemple - Vous voulez faire tourner un serveur DNS disponible + pour le publique sur votre firewall :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACCEPTnetfwudp
    -     		53#permet les accès DNSdepuis Internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACCEPTnetfwudp
    +     		53#permet les accès DNSdepuis Internet
    -
    -
    - -
    -

    Ces deux règles seront, bien sur, ajoutées aux règles décrites - dans "Vous pouvez installer/configurer un cache dns (Caching Name Server) - sur votre firewall ou dans la DMZ".

    -
    - -
    -

    Si vous ne savez pas quel port ou protocole une application - particulière utilise, regardez ici.

    -
    - -
    -

    Important: Je ne vous recommande pas d'autoriser le telnet - depuis ou vers l'Internet car il utilise du texte en clair (même pour le -login et le mot de passe !). Si vous voulez avoir un accès au shell de votre -firewall depuis Internet, utilisez SSH :

    -
    - -
    -
    +
    +
    + +
    +

    Ces deux règles seront, bien sur, ajoutées aux règles décrites + dans "Vous pouvez installer/configurer un cache dns (Caching Name Server) + sur votre firewall ou dans la DMZ".

    +
    + +
    +

    Si vous ne savez pas quel port ou protocole une application + particulière utilise, regardez ici.

    +
    + +
    +

    Important: Je ne vous recommande pas d'autoriser le telnet + depuis ou vers l'Internet car il utilise du texte en clair (même pour le + login et le mot de passe !). Si vous voulez avoir un accès au shell de votre + firewall depuis Internet, utilisez SSH :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    +
    +
    -
    -
    - -
    + +
    + +

    - Et maintenant, éditez /etc/shorewall/rules pour rajouter les autres connexions - désirées.

    -
    - -
    + Et maintenant, éditez /etc/shorewall/rules pour rajouter les autres +connexions désirées.

    +
    + +

    Lancer et Arrêter son Firewall

    -
    - -
    +
    + +

    Arrow - La procédure d'installation configure votre -système pour lancer Shorewall au boot du système, mais au début avec la version -1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall - avec que la configuration soit finie. Une fois que vous en avez fini avec - la configuration du firewall, vous pouvez permettre le lancement de Shorewall - en supprimant le fichier /etc/shorewall/startup_disabled.
    -

    - -

    IMPORTANT: Les utilisateurs des paquets .deb doivent éditer - /etc/default/shorewall et mettre 'startup=1'.
    -

    -
    - -
    -

    Le firewall est activé en utilisant la commande "shorewall - start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le - routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un - firewall qui tourne peut être relancé en utilisant la commande "shorewall - restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration - de Netfilter, utilisez "shorewall clear".

    -
    - -
    + La procédure d'installation configure votre + système pour lancer Shorewall au boot du système, mais au début avec la +version 1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de +lancer Shorewall avec que la configuration soit finie. Une fois que vous +en avez fini avec la configuration du firewall, vous pouvez permettre le +lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
    +

    + +

    IMPORTANT: Les utilisateurs des paquets .deb doivent éditer + /etc/default/shorewall et mettre 'startup=1'.
    +

    +
    + +
    +

    Le firewall est activé en utilisant la commande "shorewall + start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, +le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un + firewall qui tourne peut être relancé en utilisant la commande "shorewall + restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration + de Netfilter, utilisez "shorewall clear".

    +
    + +

    - L'exemple pour trois interfaces suppose que vous voulez permettre le -routage depuis/vers eth1 (votre réseau local) et eth2(DMZ) - lorsque Shorewall est arrêté. Si ces deux interfaces ne sont pas -connectées à votre réseau local et votre DMZ, ou si vous voulez permettre -un ensemble d'hôtes différents, modifiez /etc/shorewall/routestopped en -conséquence.

    -
    - -
    -

    ATTENTION: Si vous êtes connecté à votre firewall depuis Internet, -n'essayez pas une commande "shorewall stop" tant que vous n'avez pas ajouté -une entrée pour votre adresse IP (celle à partir de laquelle vous êtes connectée) -dans /etc/shorewall/routestopped. - De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; - il est plus intéressant de créer une eth1 (votre réseau local) et eth2(DMZ) + lorsque Shorewall est arrêté. Si ces deux interfaces ne sont pas +connectées à votre réseau local et votre DMZ, ou si vous voulez permettre +un ensemble d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.

    +
    + +
    +

    ATTENTION: Si vous êtes connecté à votre firewall depuis +Internet, n'essayez pas une commande "shorewall stop" tant que vous n'avez +pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous +êtes connectée) dans /etc/shorewall/routestopped. + De la même manière, je ne vous recommande pas d'utiliser "shorewall restart"; + il est plus intéressant de créer une configuration alternativeet de la - tester en utilisant la commande alternativeet de la + tester en utilisant la commande "shorewall try".

    -
    - + +

    Last updated 05/19/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Eastep
    -

    +

    +
    diff --git a/STABLE/documentation/traffic_shaping.htm b/STABLE/documentation/traffic_shaping.htm index fd0c298c1..4b127c911 100644 --- a/STABLE/documentation/traffic_shaping.htm +++ b/STABLE/documentation/traffic_shaping.htm @@ -1,337 +1,337 @@ - + - + - + - + Traffic Shaping - + - - - + + - - - + + + +
    - - + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Traffic Shaping/Control

    -
    - -

    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. It is also necessary + +

    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. It is also necessary to be running Linux Kernel 2.4.18 or later.

    - +

    Shorewall traffic shaping support consists of the following:

    - +
      -
    • A new TC_ENABLED parameter in /etc/shorewall.conf. +
    • A new TC_ENABLED parameter in /etc/shorewall.conf. Traffic Shaping also requires that you enable packet mangling.
      • -
    • A new CLEAR_TC parameter in /etc/shorewall.conf (Added - in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), - the setting of this variable determines whether Shorewall clears the traffic +
    • A new CLEAR_TC parameter in /etc/shorewall.conf (Added + in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), + the setting of this variable determines whether Shorewall clears the traffic shaping configuration during Shorewall [re]start and Shorewall stop.
      -
      • -
    • /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. +
      • +
    • /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. 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 + href="ftp://ftp.shorewall.net/pub/shorewall/cbq">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. 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.
      -
      - You can generally use off-the-shelf traffic shaping scripts by +
      + 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 + href="http://lartc.org/wondershaper/">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.
      • - +
    - Shorewall allows you to start traffic shaping when Shorewall itself - starts or it allows you to bring up traffic shaping when you bring up -your interfaces.
    -
    - To start traffic shaping when Shorewall starts:
    - + Shorewall allows you to start traffic shaping when Shorewall itself + starts or it allows you to bring up traffic shaping when you bring up your + interfaces.
    +
    + To start traffic shaping when Shorewall starts:
    +
      -
    1. Set TC_ENABLED=Yes and CLEAR_TC=Yes
      2. -
    2. Supply an /etc/shorewall/tcstart script to configure your traffic +
    3. Set TC_ENABLED=Yes and CLEAR_TC=Yes
      4. +
    4. Supply an /etc/shorewall/tcstart script to configure your traffic shaping rules.
      5. -
    5. Optionally supply an /etc/shorewall/tcclear script to stop traffic - shaping. That is usually unnecessary.
      6. -
    6. If your tcstart script uses the 'fwmark' classifier, you can +
    7. Optionally supply an /etc/shorewall/tcclear script to stop +traffic shaping. That is usually unnecessary.
      8. +
    8. If your tcstart script uses the 'fwmark' classifier, you can mark packets using entries in /etc/shorewall/tcrules.
      9. - +
    - To start traffic shaping when you bring up your network interfaces, - you will have to arrange for your traffic shaping configuration script -to be run at that time. How you do that is distribution dependent and will + To start traffic shaping when you bring up your network interfaces, + you will have to arrange for your traffic shaping configuration script +to be run at that time. How you do that is distribution dependent and will not be covered here. You then should:
    - +
      -
    1. Set TC_ENABLED=Yes and CLEAR_TC=No
      2. -
    2. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear +
    3. Set TC_ENABLED=Yes and CLEAR_TC=No
      4. +
    4. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.
      5. -
    5. If your tcstart script uses the 'fwmark' classifier, +
    6. If your tcstart script uses the 'fwmark' classifier, you can mark packets using entries in /etc/shorewall/tcrules.
      7. - +
    - +

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

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

    - -

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

    - +

    + +

    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. Beginning -with Shorewall version 1.3.14, this value may be optionally followed by ":" -and either 'F' or 'P' to designate that the marking will occur in the FORWARD -or PREROUTING chains respectively. If this additional specification is omitted, -the chain used to mark packets will be determined by the setting of the -MARK_IN_FORWARD_CHAIN option in shorewall.conf.
      -
      - 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 +
    • MARK - Specifies the mark value is to be assigned +in case of a match. This is an integer in the range 1-255. Beginning +with Shorewall version 1.3.14, this value may be optionally followed by +":" and either 'F' or 'P' to designate that the marking will occur in the +FORWARD or PREROUTING chains respectively. If this additional specification +is omitted, the chain used to mark packets will be determined by the setting +of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
      +
      + 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 +
      • +
    • 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 +
      • +
    • 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 and eth3 should be marked with - 2. All packets originating on the firewall itself should be marked -with 3.

    - + +

    Example 1 - All packets arriving on eth1 should be marked + with 1. All packets arriving on eth2 and eth3 should be marked with + 2. All packets originating on the firewall itself should be marked with + 3.

    + - + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    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  
    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 + +

    Example 2 - All GRE (protocol 47) packets not originating + on the firewall and destined for 155.186.235.151 should be marked with 12.

    - + - + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    120.0.0.0/0155.186.235.15147  
    120.0.0.0/0155.186.235.15147  
    - -

    Example 3 - All SSH packets originating in 192.168.1.0/24 + +

    Example 3 - All SSH packets originating in 192.168.1.0/24 and destined for 155.186.235.151 should be marked with 22.

    - + - + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    22192.168.1.0/24155.186.235.151tcp22 
    22192.168.1.0/24155.186.235.151tcp22 
    - +

    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 + href="http://lartc.org/wondershaper/">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 /etc/shorewall/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 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 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 that went with this tcstart file is shown in Example 1 - above. You can look at my configuration to -see why I wanted shaping of this type.

    - + +
    + 
    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 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 that went with this tcstart file is shown in Example 1 + above. You can look at my configuration to +see why I wanted shaping of this type.
    +

    +
      -
    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 +
    2. 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).
      3. -
    3. My laptop and local systems could use up to 224kbits/second.
      4. -
    4. My firewall could use up to 20kbits/second.
      5. - +
    5. My laptop and local systems could use up to 224kbits/second.
      6. +
    6. My firewall could use up to 20kbits/second.
      7. +
    - You see the rest of my Shorewall configuration + You see the rest of my Shorewall configuration to see how this fit in.
    - +

    Last Updated 3/19/2003 - Tom Eastep

    - -

    Copyright + +

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

    +

    +



    diff --git a/STABLE/documentation/troubleshoot.htm b/STABLE/documentation/troubleshoot.htm index f39e5c545..e250c020c 100644 --- a/STABLE/documentation/troubleshoot.htm +++ b/STABLE/documentation/troubleshoot.htm @@ -1,224 +1,226 @@ - + Shorewall Troubleshooting - + - + - + - - - + + - - - + + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    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.

    - + +

    Check the Shorewall Errata to be + 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.

    - + +

    Check the FAQs for solutions to common + 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: +
      -
    • 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 -- If you are using Shorewall +
    • 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 -- If you are using Shorewall 1.4.0 or later, you should find the message near the end of the log.
      • -
    • If you still can't determine what's wrong then see the - support page.
      • - +
    • 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:
    - -
    + 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:  -
    +
    + 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) - +
    + 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 + +

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

    - -

    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 ("/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:

    - + +

    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.

    + +

    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 ("/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:

    +

    LOGRATE=""
    - LOGBURST=""

    - -

    This way, you will see all of the log messages being generated + 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 + +

    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

    - +

    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:

    - + +

    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:

    +

    ACCEPT    dmz    loc    udp    53
    -

    - -

    See FAQ 17 for additional information - about how to interpret the chain name appearing in a Shorewall log message.
    -

    - +

    + +

    See FAQ 17 for additional information + about how to interpret the chain name appearing in a Shorewall log message.
    +

    +

    'Ping' Problems?

    - Either can't ping when you think you should be able to or are able to + Either can't ping when you think you should be able to or are able to ping when you think that you shouldn't be allowed? Shorewall's 'Ping' Management is described here.
    - +

    Other Gotchas

    - + - +

    Still Having Problems?

    - +

    See the support page.
    -

    - +

    +
    -     +

    Last updated 4/29/2003 - Tom Eastep

    - -

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

    + +

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

    +
    diff --git a/STABLE/documentation/two-interface.htm b/STABLE/documentation/two-interface.htm index 14192e6ff..4c26f9b66 100644 --- a/STABLE/documentation/two-interface.htm +++ b/STABLE/documentation/two-interface.htm @@ -1,715 +1,533 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
    + bgcolor="#3366ff" height="90"> +
    +

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

    - + configure the above setup using the Mandrake "Internet Connection Sharing" + applet. From the Mandrake Control Center, select "Network & Internet" + then "Connection Sharing".
    +

    +

    Note however, that the Shorewall configuration produced by Mandrake - Internet Connection Sharing is strange and is apt to confuse you if you use - the rest of this documentation (it has two local zones; "loc" and "masq" - where "loc" is empty; this conflicts with this documentation which assumes - a single local zone "loc"). We therefore recommend that once you have set - up this sharing that you uninstall the Mandrake Shorewall RPM and install - the one from the download page then follow the - instructions in this Guide.
    -

    - + Internet Connection Sharing is strange and is apt to confuse you if you +use the rest of this documentation (it has two local zones; "loc" and "masq" + where "loc" is empty; this conflicts with this documentation which assumes + a single local zone "loc"). We therefore recommend that once you have set + up this sharing that you uninstall the Mandrake Shorewall RPM and install + the one from the download page then follow the + instructions in this Guide.
    +

    +

    Shorewall requires 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 - . Configuration notes that are unique to LEAF/Bering are - marked with (LEAF Logo) + . Configuration notes that are unique to LEAF/Bering +are marked with (LEAF Logo) -

    - +

    +

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

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

    - +

    +

    -     WARNING: Your ISP might -assign your external interface an RFC 1918 address. If that address is -in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC -1918 subnet for your local network.
    -

    - +     WARNING: Your ISP might + assign your external interface an RFC 1918 address. If that address is + in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC + 1918 subnet for your local network.
    +

    +

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

    - +     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
      -
      • - +
    • NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
      • +
    • 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.

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

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

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

      -
      • -
    • -

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

    Other Connections

    -
    - -
    -

    The two-interface sample includes the following rules:

    -
    - -
    -
    + is:

    + +
    - + @@ -719,308 +537,498 @@ do that by adding the following rules in /etc/shorewall/rules.

    - - + - - - - - - - - - - - - - - - - -
    ACTION SOURCE DESTINATION ORIGINAL ADDRESS
    ACCEPTfwDNAT nettcp53  
    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.

    -
    - -
    -

    The sample also includes:

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

    -
    - -
    -

    If you wish to enable other connections between your firewall - and other systems, the general format is:

    -
    - -
    -
    - - - - - - - - - - - - - - - + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone>loc:<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:

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

      +
      • +
    • +

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

    Other Connections

    +
    + +
    +

    The two-interface sample includes the following rules:

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

    +
    + +
    +

    The sample also includes:

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

    +
    + +
    +

    If you wish to enable other connections between your firewall + and other systems, the general format is:

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

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

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible - with Jacques's Shorewall configuration.

    - -
    -
    +     Bering users will want to add the following two rules to be compatible + with Jacques's Shorewall configuration.

    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    -     		fwudp
    -     		53
    -     		#Allow DNS Cache towork
    -
    ACCEPTlocfwtcp80#Allow weblet to work
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    +     		fwudp
    +     		53
    +     		#Allow DNS Cache towork
    +
    ACCEPTlocfwtcp80#Allow weblet to work
    +
    -
    -
    - +
    +
    +


    - -     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 /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 2/21/2003 - + +

    Last updated 6/27/2003 - Tom Eastep

    - +

    Copyright 2002, 2003 - Thomas M. Eastep
    -

    + Thomas M. Eastep
    +

    +
    +
    diff --git a/STABLE/documentation/two-interface_fr.html b/STABLE/documentation/two-interface_fr.html index 405e6685d..5262afb6f 100755 --- a/STABLE/documentation/two-interface_fr.html +++ b/STABLE/documentation/two-interface_fr.html @@ -1,1377 +1,1380 @@ - + Two-Interface Firewall - + - + - + - + - + - + - -


    -

    - + - - - + + - - - + + + +
    + bgcolor="#3366ff"> +

    Basic Two-Interface Firewall

    -
    - +

    Version 2.0.1 Française

    - +


    - Notes du traducteur :
    - Je ne prétends pas être un vrai traducteur dans le sens ou -mon travail n’est pas des plus précis (loin de là...). Je ne -me suis pas attaché à une traduction exacte du texte, mais -plutôt à en faire une version française intelligible -par tous (et par moi). Les termes techniques sont la plupart du temps conservés -sous leur forme originale et mis entre parenthèses car vous pouvez -les retrouver dans le reste des documentations ainsi que dans les fichiers -de configuration. N’hésitez pas à me contacter afin d’améliorer -ce document VETSEL Patrice - (merci à JMM pour sa relecture et ses commentaires pertinents, ainsi -qu'à Tom EASTEP pour son formidable outil et sa disponibilité)    .
    -
    -

    - -

    Mettre en place un système Linux en tant que firewall -pour un petit réseau est une chose assez simple, si vous comprenez -les bases et suivez la documentation.

    - -

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il se -focalise sur ce qui est nécessaire pour configurer Shorewall, dans -son utilisation la plus courante :

    - + Notes du traducteur :
    + Je ne prétends pas être un vrai traducteur dans le sens ou +mon travail n’est pas des plus précis (loin de là...). Je ne +me suis pas attaché à une traduction exacte du texte, mais plutôt +à en faire une version française intelligible par tous (et +par moi). Les termes techniques sont la plupart du temps conservés + sous leur forme originale et mis entre parenthèses car vous pouvez + les retrouver dans le reste des documentations ainsi que dans les fichiers + de configuration. N’hésitez pas à me contacter afin d’améliorer + ce document VETSEL Patrice + (merci à JMM pour sa relecture et ses commentaires pertinents, ainsi + qu'à Tom EASTEP pour son formidable outil et sa disponibilité)    .
    +
    +

    + +

    Mettre en place un système Linux en tant que firewall + pour un petit réseau est une chose assez simple, si vous comprenez + les bases et suivez la documentation.

    + +

    Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il +se focalise sur ce qui est nécessaire pour configurer Shorewall, dans + son utilisation la plus courante :

    +
      -
    • -

      Un système Linux utilisé - en tant que firewall/routeur pour un petit réseau local.

      -
      • -
    • +
    • +

      Un système Linux utilisé + en tant que firewall/routeur pour un petit réseau local.

      +
      • +

    • Une seule adresse IP publique.

      -
      • -
    • -

      Une connexion Internet par le biais d'un modem câble, ADSL, -ISDN, "Frame Relay", RTC ...

      -
      • - + +
    • +

      Une connexion Internet par le biais d'un modem câble, ADSL, + ISDN, "Frame Relay", RTC ...

      +
      • +
    - +

    Voici un schéma d'une installation typique.

    - +

    -

    - -

    Si vous faites tourner Shorewall sous Mandrake 9.0 ou plus récent, -vous pouvez facilement réaliser la configuration ci-dessus en utilisant -l'applet Mandrake "Internet Connection Sharing". Depuis le "Mandrake Control -Center", sélectionnez "Network & Internet" et "Connection Sharing". -Vous ne devriez pas avoir besoin de vous référer à ce -guide.

    - -

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. -Vous pouvez voir si le paquet est installé en vérifiant -la présence du programme ip sur votre système de firewall. Sous -root, utilisez la commande 'which' pour rechercher le programme :

    - +

    + +

    Si vous faites tourner Shorewall sous Mandrake 9.0 ou plus récent, + vous pouvez facilement réaliser la configuration ci-dessus en utilisant + l'applet Mandrake "Internet Connection Sharing". Depuis le "Mandrake Control + Center", sélectionnez "Network & Internet" et "Connection Sharing". + Vous ne devriez pas avoir besoin de vous référer à +ce guide.

    + +

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. + Vous pouvez voir si le paquet est installé en vérifiant + la présence du programme ip sur votre système de firewall. +Sous root, utilisez la commande 'which' pour rechercher le programme :

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

    Je vous recommande dans un premier temps de parcourir tout le guide pour -vous familiariser avec ce qui va se passer, et de revenir au début -en effectuant le changements dans votre configuration. Les points où, -les changements dans la configuration sont recommandées, sont signalés -par une Je vous recommande dans un premier temps de parcourir tout le guide pour + vous familiariser avec ce qui va se passer, et de revenir au début + en effectuant le changements dans votre configuration. Les points où, + les changements dans la configuration sont recommandées, sont signalés + par une - .

    - + .

    +

    -     Si vous éditez vos fichiers de configuration sur -un système Windows, vous devez les sauver comme des fichiers Unix si -votre éditeur offre cette option sinon vous devez les faire passer -par dos2unix avant d'essayer de les utiliser. De la même manière, -si vous copiez un fichier de configuration depuis votre disque dur Windows -vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser -avec Shorewall.

    - +     Si vous éditez vos fichiers de configuration +sur un système Windows, vous devez les sauver comme des fichiers +Unix si votre éditeur offre cette option sinon vous devez les faire +passer par dos2unix avant d'essayer de les utiliser. De la même manière, + si vous copiez un fichier de configuration depuis votre disque dur Windows + vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser + avec Shorewall.

    + - +

    Les Concepts de Shorewall

    - +

    -     Les fichiers de configuration pour Shorewall sont dans -le répertoire /etc/shorewall -- pour de simples configurations, vous -n'aurez seulement à faire qu'avec quelques fichiers comme décrit - dans ce guide. Après avoir installé -Shorewall, télé chargez le two-interface sample, -un-tarez le (tar -zxvf two-interfaces.tgz) et copiez les fichiers vers /etc/shorewall +     Les fichiers de configuration pour Shorewall sont dans + le répertoire /etc/shorewall -- pour de simples configurations, vous + n'aurez seulement à faire qu'avec quelques fichiers comme décrit + dans ce guide. Après avoir installé Shorewall, +télé chargez le two-interface sample, +un-tarez le (tar -zxvf two-interfaces.tgz) et copiez les fichiers vers /etc/shorewall (ces fichiers remplaceront les fichiers de même nom).

    - -

    Parallèlement à la présentation de chacun des fichiers, -je vous suggère de regarder le fichier qui se trouve réellement -sur votre système -- tous les fichiers contiennent des instructions -de configuration détaillées et des valeurs par défaut.

    - -

    Shorewall voit le réseau où il tourne, comme un ensemble -de zones. Dans une configuration avec deux interfaces, les noms des -zones suivantes sont utilisés:

    - + +

    Parallèlement à la présentation de chacun des fichiers, + je vous suggère de regarder le fichier qui se trouve réellement + sur votre système -- tous les fichiers contiennent des instructions + de configuration détaillées et des valeurs par défaut.

    + +

    Shorewall voit le réseau où il tourne, comme un ensemble + de zones. Dans une configuration avec deux interfaces, les noms des + zones suivantes sont utilisés:

    + - - - + + - + - - - + + + - + - - - + + + - + - - - + + + +
    +

    Nom

    -     		+

    Description

    -
    +

    net

    -     		+

    Internet

    -
    +

    loc

    -     		+

    Votre réseau local

    -
    - +

    Les zones sont définies dans le fichier/etc/shorewall/zones .

    - -

    Shorewall reconnaît aussi le système de firewall comme sa -propre zone - par défaut, le firewall est connu comme fw.

    - -

    Les règles à propos de quel trafic autoriser, et de quel -trafic interdire sont exprimées en terme de zones.

    - + +

    Shorewall reconnaît aussi le système de firewall comme sa + propre zone - par défaut, le firewall est connu comme fw.

    + +

    Les règles à propos de quel trafic autoriser, et de quel + trafic interdire sont exprimées en terme de zones.

    + - -

    Pour chaque connexion demandant à entrer dans le firewall, la requête -est en premier lieu comparée par rapport au fichier /etc/shorewall/rules. -Si aucune règle dans ce fichier ne correspond à la demande de -connexion alors la première politique dans le fichier /etc/shorewall/policy -qui y correspond sera appliquée. Si cette politique est REJECT ou DROP  -la requête est dans un premier temps comparée par rapport aux -règles contenues dans /etc/shorewall/common.

    - -

    Le fichier /etc/shorewall/policy inclue dans l'archive d'exemple (two-interface) -a les politiques suivantes:

    - + +

    Pour chaque connexion demandant à entrer dans le firewall, la requête + est en premier lieu comparée par rapport au fichier /etc/shorewall/rules. + Si aucune règle dans ce fichier ne correspond à la demande +de connexion alors la première politique dans le fichier /etc/shorewall/policy + qui y correspond sera appliquée. Si cette politique est REJECT ou +DROP  la requête est dans un premier temps comparée par +rapport aux règles contenues dans /etc/shorewall/common.

    + +

    Le fichier /etc/shorewall/policy inclue dans l'archive d'exemple (two-interface) + a les politiques suivantes:

    +
    -
    +
    - - - + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + +
    +

    Source Zone

    -     		+

    Destination Zone

    -     		+

    Policy

    -     		+

    Log Level

    -     		+

    Limit:Burst

    -
    +

    loc

    -     		+

    net

    -     		+

    ACCEPT

    -     		+

     

    -     		+

     

    -
    +

    net

    -     		+

    all

    -     		+

    DROP

    -     		+

    info

    -     		+

     

    -
    +

    all

    -     		+

    all

    -     		+

    REJECT

    -     		+

    info

    -     		+

     

    -
    -
    +
    - -
    Dans le fichier d'exemple (two-interface), la ligne suivante est -inclue mais elle est commentée. Si vous voulez que votre firewall puisse -avoir un accès complet aux serveurs sur Internet, décommentez -la ligne.
    - + +
    Dans le fichier d'exemple (two-interface), la ligne suivante +est inclue mais elle est commentée. Si vous voulez que votre firewall +puisse avoir un accès complet aux serveurs sur Internet, décommentez + la ligne.
    +
    -
    +
    - - - + + - + - + - + - + - - - + + + - + - + - + - + - - - + + + +
    +

    Source Zone

    -     		+

    Destination Zone

    -     		+

    Policy

    -     		+

    Log Level

    -     		+

    Limit:Burst

    -
    +

    fw

    -     		+

    net

    -     		+

    ACCEPT

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    Ces politiques vont:

    - +
      -
    1. -

      permettre toutes les demandes de connexion -depuis votre réseau local vers l'Internet

      -
      2. -
    2. -

      drop (ou ignorer) toutes les demandes -de connexion depuis l'Internet vers votre firewall ou votre réseau -local.

      -
      3. -
    3. -

      Facultativement accepter toutes les - demandes de connexion de votre firewall vers l'Internet (si vous avez dé -commenté la politique additionnelle)

      -
      4. -
    4. +
    5. +

      permettre toutes les demandes de connexion + depuis votre réseau local vers l'Internet

      +
      6. +
    6. +

      drop (ou ignorer) toutes les demandes + de connexion depuis l'Internet vers votre firewall ou votre réseau + local.

      +
      7. +
    7. +

      Facultativement accepter toutes les + demandes de connexion de votre firewall vers l'Internet (si vous avez +dé commenté la politique additionnelle)

      +
      8. +

    8. reject (rejeter) toutes les autres demandes de connexion.

      -
      9. - + +
    - +

    -     A ce point, éditez votre fichier /etc/shorewall/policy -et faite les changements que vous désirez.

    - +     A ce point, éditez votre fichier /etc/shorewall/policy + et faite les changements que vous désirez.

    +

    Network Interfaces

    - +

    -

    - -

    Le firewall a deux interfaces de réseau. Lorsque la -connexion Internet passe par le câble ou par un ROUTEUR (pas un simple -modem) ADSL (non USB), l'interface vers l'extérieur (External Interface) -sera l'adaptateur sur lequel est connecté le routeur (e.g., eth0)  -à moins que vous ne vous connectiez par Point-to-PointProtocol -overEthernet (PPPoE) ou par Point-to-PointTunnelingProtocol(PPTP), - dans ce cas l'interface extérieure sera une interface de type ppp -(e.g., ppp0). Si vous vous connectez par un simple modem (RTC), votre -interface extérieure sera aussi ppp0. Si votre connexion passe -par Numéris (ISDN), votre interface extérieure seraippp0.

    - +

    + +

    Le firewall a deux interfaces de réseau. Lorsque la + connexion Internet passe par le câble ou par un ROUTEUR (pas un simple + modem) ADSL (non USB), l'interface vers l'extérieur (External +Interface) sera l'adaptateur sur lequel est connecté le routeur +(e.g., eth0)  à moins que vous ne vous connectiez +par Point-to-PointProtocol overEthernet +(PPPoE) ou par Point-to-PointTunnelingProtocol(PPTP), + dans ce cas l'interface extérieure sera une interface de type ppp + (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), votre + interface extérieure sera aussi ppp0. Si votre connexion passe + par Numéris (ISDN), votre interface extérieure seraippp0.

    +

    -     Si votre interface vers l'extérieur estppp0 -ou ippp0  alors vous mettrez CLAMPMSS=yes dans ppp0 + ou ippp0  alors vous mettrez CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

    - -

    Votre Internal Interface (interface vers votre réseau -local -> LAN) sera un adaptateur Ethernet (eth1 ou eth0) et sera connectée -à un hub ou switch (ou un PC avec un câble croisé). Vos -autres ordinateurs seront connectés à ce même hub/switch

    - + +

    Votre Internal Interface (interface vers votre réseau + local -> LAN) sera un adaptateur Ethernet (eth1 ou eth0) et sera connectée + à un hub ou switch (ou un PC avec un câble croisé). +Vos autres ordinateurs seront connectés à ce même hub/switch

    +

    - Ne connectez pas l'interface interne et externe sur le même -hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez -pas que ce soit shorewall qui ne marche pas.

    - + Ne connectez pas l'interface interne et externe sur le même + hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez + pas que ce soit shorewall qui ne marche pas.

    +

    -     Le fichier de configuration d'exemple pour deux interfaces -suppose que votre interface externe est eth0et que l'interne est eth1. - Si votre configuration est différente, vous devrez modifier le fichier -/etc/shorewall/interfaces en conséquence. -Tant que vous y êtes, vous pourriez parcourir la liste des options qui -sont spécifiées pour les interfaces. Quelques trucs:

    - +     Le fichier de configuration d'exemple pour deux interfaces + suppose que votre interface externe est eth0et que l'interne est +eth1. Si votre configuration est différente, vous devrez modifier +le fichier /etc/shorewall/interfaces +en conséquence. Tant que vous y êtes, vous pourriez parcourir +la liste des options qui sont spécifiées pour les interfaces. +Quelques trucs:

    +
      -
    • -

      Si votre interface vers l'extérieur est ppp0 - ou ippp0, vous pouvez remplacer le "detect" dans la seconde colonne -par un "-".

      -
      • -
    • -

      Si votre interface vers l'extérieur est ppp0 -ou ippp0 ou si vous avez une adresse IP statique, vous pouvez enlever -"dhcp" dans la liste des options.

      -
      • - +
    • +

      Si votre interface vers l'extérieur est ppp0 + ou ippp0, vous pouvez remplacer le "detect" dans la seconde colonne + par un "-".

      +
      • +
    • +

      Si votre interface vers l'extérieur est ppp0 + ou ippp0 ou si vous avez une adresse IP statique, vous pouvez enlever + "dhcp" dans la liste des options.

      +
      • +
    - +

    Adresses IP

    - -

    Avant d'aller plus loin, nous devons dire quelques mots au -sujet de Internet Protocol (IP) addresses. Normalement, votre fournisseur -Internet (ISP) vous assignera une seule adresse IP (single PublicIP - address). Cette adresse peut être assignée par le Dynamic - Host Configuration Protocol(DHCP) ou lors de l'établissement -de votre connexion lorsque vous vous connectez (modem standard) ou établissez -votre connexion PPP. Dans de rares cas , votre provider peut vous assigner -une adresse statique (staticIP address); cela signifie que vous devez -configurer l'interface externe de votre firewall afin d'utiliser cette adresse -de manière permanente. Votre adresse externe assignée, elle -va être partagée par tous vos systèmes lors de l'accès - à Internet. Vous devrez assigner vos propres adresses dans votre -réseau local (votre interface interne sur le firewall  ainsi -que les autres ordinateurs). La RFC 1918 réserve plusieurs plages -d'IP (PrivateIP address ranges) à cette fin :

    - + +

    Avant d'aller plus loin, nous devons dire quelques mots au + sujet de Internet Protocol (IP) addresses. Normalement, votre fournisseur + Internet (ISP) vous assignera une seule adresse IP (single PublicIP + address). Cette adresse peut être assignée par le Dynamic + Host Configuration Protocol(DHCP) ou lors de l'établissement de +votre connexion lorsque vous vous connectez (modem standard) ou établissez + votre connexion PPP. Dans de rares cas , votre provider peut vous assigner + une adresse statique (staticIP address); cela signifie que vous devez + configurer l'interface externe de votre firewall afin d'utiliser cette adresse + de manière permanente. Votre adresse externe assignée, elle + va être partagée par tous vos systèmes lors de l'accès + à Internet. Vous devrez assigner vos propres adresses dans votre réseau +local (votre interface interne sur le firewall  ainsi que les autres +ordinateurs). La RFC 1918 réserve plusieurs plages d'IP (PrivateIP +address ranges) à cette fin :

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

    -     Avant de lancer Shorewall, vous devriez regarder l'adresse -IP de votre interface externe, et si elle est dans les plages précédentes, -vous devriez enlever l'option 'norfc1918' dans la ligne concernant l'interface -externe dans le fichier /etc/shorewall/interfaces.

    - -

    Vous devrez assigner vos adresses depuis le même sous-réseau -(sub-network/subnet). Pour ce faire, nous pouvons considérer -un sous-réseau dans une plage d'adresses x.y.z.0 - x.y.z.255. Chaque -sous-réseau aura un masque (Subnet Mask) de 255.255.255.0. L'adresse -x.y.z.0 est réservée comme l'adresse de sous-réseau (Subnet -Address) et x.y.z.255 est réservée en tant qu'adresse de -broadcast (Subnet Broadcast Address). Dans Shorewall, un sous-réseau -est décrit en utilisant la notation Classless InterDomain -Routing (CIDR) qui consiste en l'adresse du sous-réseau suivie -par "/24". Le "24" se réfère au nombre consécutif de -bits marquant "1" dans la partie gauche du masque de sous-réseau.

    - +     Avant de lancer Shorewall, vous devriez regarder l'adresse + IP de votre interface externe, et si elle est dans les plages précédentes, + vous devriez enlever l'option 'norfc1918' dans la ligne concernant l'interface + externe dans le fichier /etc/shorewall/interfaces.

    + +

    Vous devrez assigner vos adresses depuis le même sous-réseau + (sub-network/subnet). Pour ce faire, nous pouvons considérer + un sous-réseau dans une plage d'adresses x.y.z.0 - x.y.z.255. Chaque + sous-réseau aura un masque (Subnet Mask) de 255.255.255.0. +L'adresse x.y.z.0 est réservée comme l'adresse de sous-réseau +(Subnet Address) et x.y.z.255 est réservée en tant qu'adresse +de broadcast (Subnet Broadcast Address). Dans Shorewall, un +sous-réseau est décrit en utilisant la notation Classless InterDomain + Routing (CIDR) qui consiste en l'adresse du sous-réseau suivie + par "/24". Le "24" se réfère au nombre consécutif de + bits marquant "1" dans la partie gauche du masque de sous-réseau.

    +

    Un exemple de sous-réseau (sub-network) :

    - +
    -
    +
    - - - + + - + - - - + + + - + - - - + + + - + - - - + + + - + - - - + + + +
    +

    Plage:

    -     		+

    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

    -
    -
    +
    - -

    Il est de mise d'assigner l'interface interne (LAN) à -la première adresse utilisable du sous-réseau (10.10.10.1 dans -l'exemple précédent) ou la dernière adresse utilisable -(10.10.10.254).

    - -

    L'un des buts d'un sous-réseau est de permettre à -tous les ordinateurs dans le sous-réseau de savoir avec quels autres -ordinateurs ils peuvent communiquer directement. Pour communiquer avec des -systèmes en dehors du sous-réseau, les ordinateurs envoient -des paquets à travers le gateway (routeur).

    - + +

    Il est de mise d'assigner l'interface interne (LAN) à + la première adresse utilisable du sous-réseau (10.10.10.1 +dans l'exemple précédent) ou la dernière adresse utilisable + (10.10.10.254).

    + +

    L'un des buts d'un sous-réseau est de permettre à + tous les ordinateurs dans le sous-réseau de savoir avec quels autres + ordinateurs ils peuvent communiquer directement. Pour communiquer avec des + systèmes en dehors du sous-réseau, les ordinateurs envoient + des paquets à travers le gateway (routeur).

    +

    -     Vos ordinateurs en local (ordinateur 1 et ordinateur -2 dans le diagramme) devraient être configurés avec leur passerelle - par défaut (default gateway) pointant sur l'adresse IP de -l'interface interne du firewall.

    - -

    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.

    - -

    Le reste de ce guide assumera que vous avez configuré -votre réseau comme montré ci-dessous :

    - +     Vos ordinateurs en local (ordinateur 1 et ordinateur +2 dans le diagramme) devraient être configurés avec leur passerelle + par défaut (default gateway) pointant sur l'adresse IP de l'interface +interne du firewall.

    + +

    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.

    + +

    Le reste de ce guide assumera que vous avez configuré + votre réseau comme montré ci-dessous :

    +

    -

    - -

    La passerelle par défaut pour les ordinateurs 1 et -2 devrait être 10.10.10.254.

    - +

    + +

    La passerelle par défaut pour les ordinateurs 1 et + 2 devrait être 10.10.10.254.

    +

    IP Masquerading (SNAT)

    - -

    Les adresses réservées par la RFC 1918 sont -parfois désignées comme non-routables car les routeurs -Internet (backbone) ne font pas circuler les paquets qui ont une adresse de -destination appartenant à la RFC-1918. Lorsqu'un de vos systèmes -en local (supposons l'ordinateur1) demande une connexion à un serveur -par Internet, le firewall doit appliquer un NAT (Network Address Translation). -Le firewall ré écrit l'adresse source dans le paquet, et l'a -remplace par l'adresse de l'interface externe du firewall; en d'autres mots, -le firewall fait croire que c'est lui même qui initie la connexion. - Ceci est nécessaire afin que l'hôte de destination soit capable -de renvoyer les paquets au firewall (souvenez vous que les paquets qui ont -pour adresse de destination, une adresse réservée par la RFC -1918 ne pourront pas être routés à travers Internet, donc -l'hôte Internet ne pourra adresser sa réponse à l'ordinateur -1). Lorsque le firewall reçoit le paquet de réponse, il remet -l'adresse de destination à 10.10.10.1 et fait passer le paquet vers -l'ordinateur 1.

    - -

    Sur les systèmes Linux, ce procédé est -souvent appelé de l'IP Masquerading mais vous verrez aussi le -terme de Source Network Address Translation (SNAT) utilisé. -Shorewall suit la convention utilisée avec Netfilter:

    - + +

    Les adresses réservées par la RFC 1918 sont + parfois désignées comme non-routables car les routeurs + Internet (backbone) ne font pas circuler les paquets qui ont une adresse +de destination appartenant à la RFC-1918. Lorsqu'un de vos systèmes + en local (supposons l'ordinateur1) demande une connexion à un serveur + par Internet, le firewall doit appliquer un NAT (Network Address Translation). + Le firewall ré écrit l'adresse source dans le paquet, et l'a + remplace par l'adresse de l'interface externe du firewall; en d'autres mots, + le firewall fait croire que c'est lui même qui initie la connexion. + Ceci est nécessaire afin que l'hôte de destination soit capable + de renvoyer les paquets au firewall (souvenez vous que les paquets qui ont + pour adresse de destination, une adresse réservée par la RFC + 1918 ne pourront pas être routés à travers Internet, +donc l'hôte Internet ne pourra adresser sa réponse à +l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, +il remet l'adresse de destination à 10.10.10.1 et fait passer le paquet +vers l'ordinateur 1.

    + +

    Sur les systèmes Linux, ce procédé est + souvent appelé de l'IP Masquerading mais vous verrez aussi +le terme de Source Network Address Translation (SNAT) utilisé. + Shorewall suit la convention utilisée avec Netfilter:

    +
      -
    • -

      Masquerade désigne le cas ou vous laissez -votre firewall détecter automatiquement l'adresse de l'interface externe. -

      -
      • -
    • -

      SNAT désigne le cas où vous spécifiez -explicitement l'adresse source des paquets sortant de votre réseau -local.

      -
      • - +
    • +

      Masquerade désigne le cas ou vous laissez + votre firewall détecter automatiquement l'adresse de l'interface +externe.

      +
      • +
    • +

      SNAT désigne le cas où vous spécifiez + explicitement l'adresse source des paquets sortant de votre réseau + local.

      +
      • +
    - -

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré -avec des entrés dans le fichier /etc/shorewall/masq. Vous utiliserez -normalement le Masquerading si votre adresse IP externe est dynamique, et -SNAT si elle est statique.

    - + +

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré + avec des entrés dans le fichier /etc/shorewall/masq. Vous utiliserez + normalement le Masquerading si votre adresse IP externe est dynamique, et + SNAT si elle est statique.

    +

    -     Si votre interface externe du firewall est eth0, -vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. Dans -le cas contraire, éditez /etc/shorewall/masq et changez la première -colonne par le nom de votre interface externe, et la seconde colonne par le -nom de votre interface interne.

    - +     Si votre interface externe du firewall est eth0, + vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. Dans + le cas contraire, éditez /etc/shorewall/masq et changez la première + colonne par le nom de votre interface externe, et la seconde colonne par +le nom de votre interface interne.

    +

    -     Si votre IP externe est statique, vous pouvez la mettre -dans la troisième colonne dans /etc/shorewall/masq si vous le désirez, -de toutes façons votre firewall fonctionnera bien si vous laissez cette -colonne vide. Le fait de mettre votre IP statique dans la troisième -colonne permet un traitement des paquets sortant un peu plus efficace.
    -
    - +
    + -     Si vous utilisez les paquets Debian, vérifiez -que votre fichier de configuration shorewall.conf contient bien les valeurs +     Si vous utilisez les paquets Debian, vérifiez +que votre fichier de configuration shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas faite les changements nécessaires:

    - +
      -
    • +

    • NAT_ENABLED=Yes

      -
      • -
    • +
      • +

    • IP_FORWARDING=On

      -
      • - + +
    - +

    Port Forwarding (DNAT)

    - -

    Un de nos buts est de , peut être, faire tourner un -ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces ordinateurs -on une adresse RFC-1918, il n' est pas possible pour les clients sur Internet -de se connecter directement à eux. Il est nécessaire à -ces clients d'adresser leurs demandes de connexion au firewall qui ré -écrit l'adresse de destination de votre serveur, et fait passer le -paquet à celui-ci. Lorsque votre serveur répond, le firewall -applique automatiquement un SNAT pour ré écrire l'adresse source - dans la réponse.

    - -

    Ce procédé est appelé Port Forwarding -ou Destination Network Address Translation(DNAT). Vous configurez le -port forwarding en utilisant les règles DNAT dans le fichier /etc/shorewall/rules.

    - -

    La forme générale d'une simple règle de port forwarding -dans /etc/shorewall/rules est:

    - + +

    Un de nos buts est de , peut être, faire tourner un + ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces ordinateurs + on une adresse RFC-1918, il n' est pas possible pour les clients sur Internet + de se connecter directement à eux. Il est nécessaire à + ces clients d'adresser leurs demandes de connexion au firewall qui ré + écrit l'adresse de destination de votre serveur, et fait passer le + paquet à celui-ci. Lorsque votre serveur répond, le firewall + applique automatiquement un SNAT pour ré écrire l'adresse +source dans la réponse.

    + +

    Ce procédé est appelé Port Forwarding + ou Destination Network Address Translation(DNAT). Vous configurez +le port forwarding en utilisant les règles DNAT dans le fichier /etc/shorewall/rules.

    + +

    La forme générale d'une simple règle de port forwarding + dans /etc/shorewall/rules est:

    +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    DNAT

    -     		+

    net

    -     		+

    loc:<server local ip address> [:<server port>]

    -     		+

    <protocol>

    -     		+

    <port>

    -     		+

     

    -     		+

     

    -
    -
    +
    - -

    Exemple - vous faites tourner un serveur Web sur l'ordinateur 2 et vous -voulez faire passer les requêtes TCP sur le port 80 à ce système -:

    - + +

    Exemple - vous faites tourner un serveur Web sur l'ordinateur 2 et vous + voulez faire passer les requêtes TCP sur le port 80 à ce système + :

    +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    DNAT

    -     		+

    net

    -     		+

    loc:10.10.10.2

    -     		+

    tcp

    -     		+

    80

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    Deux points importants à garder en mémoire :

    - +
      -
    • -

      Vous devez tester la règle précédente -depuis un client à l'extérieur de votre réseau local -(c.a.d., ne pas tester depuis un navigateur tournant sur l'ordinateur 1 ou -2 ou sur le firewall). Si vous voulez avoir la possibilité d'accéder -à votre serveur web en utilisant l'adresse IP externe de votre firewall, -regardez Shorewall FAQ #2.

      -
      • -
    • -

      Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes -entrantes de connexion sur le port 80. Si vous avez des problèmes -à vous connecter à votre serveur web, essayez la règle -suivante et connectez vous sur le port 5000.

      -
      • - +
    • +

      Vous devez tester la règle précédente + depuis un client à l'extérieur de votre réseau local + (c.a.d., ne pas tester depuis un navigateur tournant sur l'ordinateur 1 +ou 2 ou sur le firewall). Si vous voulez avoir la possibilité d'accéder + à votre serveur web en utilisant l'adresse IP externe de votre firewall, + regardez Shorewall FAQ #2.

      +
      • +
    • +

      Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes + entrantes de connexion sur le port 80. Si vous avez des problèmes + à vous connecter à votre serveur web, essayez la règle + suivante et connectez vous sur le port 5000.

      +
      • +
    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    DNAT

    -     		+

    net

    -     		+

    loc:10.10.10.2:80

    -     		+

    tcp

    -     		+

    5000

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    -     A ce point, modifiez /etc/shorewall/rules pour ajouter -les règles DNAT dont vous avez besoin.

    - +     A ce point, modifiez /etc/shorewall/rules pour ajouter + les règles DNAT dont vous avez besoin.

    +

    Domain Name Server (DNS)

    - -

    Normalement, quand vous vous connectez à votre fournisseur -(ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour -le firewall (Domain Name Service) est configuré automatiquement -(c.a.d.,le fichier /etc/resolv.conf a été écrit). Il -arrive que votre provider vous donne une paire d'adresse IP pour les DNS -(name servers) afin que vous configuriez manuellement votre serveur de -nom primaire et secondaire. La manière dont le DNS est configuré -sur votre firewall est de votre responsabilité. Vous pouvez + +

    Normalement, quand vous vous connectez à votre fournisseur + (ISP), une partie consiste à obtenir votre adresse IP, votre DNS +pour le firewall (Domain Name Service) est configuré automatiquement + (c.a.d.,le fichier /etc/resolv.conf a été écrit). Il + arrive que votre provider vous donne une paire d'adresse IP pour les DNS + (name servers) afin que vous configuriez manuellement votre serveur +de nom primaire et secondaire. La manière dont le DNS est configuré + sur votre firewall est de votre responsabilité. Vous pouvez procéder d'une de ses deux façons :

    - +
      -
    • -

      Vous pouvez configurer votre système interne pour -utiliser les noms de serveurs de votre provider. Si votre fournisseur vous -donne les adresses de leurs serveurs ou si ces adresses sont disponibles -sur leur site web, vous pouvez configurer votre système interne afin -de les utiliser. Si cette information n' est pas disponible, regardez dans - /etc/resolv.conf sur votre firewall -- les noms des serveurs sont donnés -dans l'enregistrement "nameserver" dans ce fichier.

      -
      • -
    • +
    • +

      Vous pouvez configurer votre système interne +pour utiliser les noms de serveurs de votre provider. Si votre fournisseur +vous donne les adresses de leurs serveurs ou si ces adresses sont disponibles + sur leur site web, vous pouvez configurer votre système interne +afin de les utiliser. Si cette information n' est pas disponible, regardez +dans /etc/resolv.conf sur votre firewall -- les noms des serveurs sont + donnés dans l'enregistrement "nameserver" dans ce fichier.

      +
      • +

    • -     Vous pouvez configurer un cache dns (Caching Name -Server) sur votre firewall. Red Hat a un RPM pour mettre en cache -un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs - de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez -votre système interne pour utiliser le firewall lui même comme -étant le seul serveur de nom primaire. Vous pouvez utiliser l'adresse -IP interne du firewall (10.10.10.254 dans l'exemple) pour l'adresse de serveur -de nom. Pour permettre à vos systèmes locaux de discuter avec -votre serveur cache de nom, vous devez ouvrir le port 53 (UDP ET  TCP) - sur le firewall vers le réseau local; vous ferez ceci en ajoutant -les règles suivantes dans /etc/shorewall/rules.

      -
      • - +     Vous pouvez configurer un cache dns (Caching Name + Server) sur votre firewall. Red Hat a un RPM pour mettre en +cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les +utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, +vous configurez votre système interne pour utiliser le firewall +lui même comme étant le seul serveur de nom primaire. Vous +pouvez utiliser l'adresse IP interne du firewall (10.10.10.254 dans l'exemple) +pour l'adresse de serveur de nom. Pour permettre à vos systèmes +locaux de discuter avec votre serveur cache de nom, vous devez ouvrir le +port 53 (UDP ET  TCP) sur le firewall vers le réseau local; +vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules. +

      + +
    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    loc

    -     		+

    fw

    -     		+

    tcp

    -     		+

    53

    -     		+

     

    -     		+

     

    -
    +

    ACCEPT

    -     		+

    loc

    -     		+

    fw

    -     		+

    udp

    -     		+

    53

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    Autres Connexions

    - -

    Les fichiers exemples inclus dans l'archive (two-interface) -contiennent les règles suivantes :

    - + +

    Les fichiers exemples inclus dans l'archive (two-interface) + contiennent les règles suivantes :

    +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    fw

    -     		+

    net

    -     		+

    tcp

    -     		+

    53

    -     		+

     

    -     		+

     

    -
    +

    ACCEPT

    -     		+

    fw

    -     		+

    net

    -     		+

    udp

    -     		+

    53

    -     		+

     

    -     		+

     

    -
    -
    +
    - -

    Ces règles autorisent l'accès DNS à partir -de votre firewall et peuvent être enlevées si vous avez dé -commenté la ligne dans /etc/shorewall/policy autorisant toutes les -connexions depuis le firewall vers Internet.

    - + +

    Ces règles autorisent l'accès DNS à +partir de votre firewall et peuvent être enlevées si vous avez +dé commenté la ligne dans /etc/shorewall/policy autorisant +toutes les connexions depuis le firewall vers Internet.

    +

    Les exemples contiennent aussi :

    - +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    loc

    -     		+

    fw

    -     		+

    tcp

    -     		+

    22

    -     		+

     

    -     		+

     

    -
    -
    +
    - -

    Cette règle vous autorise à faire tourner un -serveur SSH sur votre firewall et à vous y connecter depuis votre réseau -local.

    - -

    Si vous voulez permettre d'autres connexions entre votre firewall -et d'autres systèmes, la forme générale est :

    - + +

    Cette règle vous autorise à faire tourner un + serveur SSH sur votre firewall et à vous y connecter depuis votre +réseau local.

    + +

    Si vous voulez permettre d'autres connexions entre votre +firewall et d'autres systèmes, la forme générale est +:

    +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    <source zone>

    -     		+

    <destination zone>

    -     		+

    <protocol>

    -     		+

    <port>

    -     		+

     

    -     		+

     

    -
    -
    +
    - -

    Exemple - Vous voulez faire tourner un serveur Web sur votre -firewall :

    - + +

    Exemple - Vous voulez faire tourner un serveur Web sur votre + firewall :

    +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    net

    -     		+

    fw

    -     		+

    tcp

    -     		+

    80

    -     		+

    #Permet l'accès Web

    -     		+

    depuis Internet

    -
    +

    ACCEPT

    -     		+

    loc

    -     		+

    fw

    -     		+

    tcp

    -     		+

    80

    -     		+

    #Permet l'accès Web

    -
    -     		+
    +

    depuis Internet

    -
    -
    +
    - -

    Ces deux règles bien sûr viennent s'ajouter aux -règles décrites précédemment dans "Vous pouvez -configurer un cache dns (Caching Name Server) sur votre firewall"

    - -

    Si vous ne savez pas quel port et quel protocole une application -particulière utilise, regardez ici.

    - -

    Important: Je ne vous recommande pas de permettre le -telnet depuis ou vers Internet car il utilise du texte en clair (même -pour le login et le mot de passe!). Si vous voulez un accès au shell -sur votre firewall depuis Internet, utilisez SSH :

    - + +

    Ces deux règles bien sûr viennent s'ajouter +aux règles décrites précédemment dans "Vous pouvez + configurer un cache dns (Caching Name Server) sur votre firewall"

    + +

    Si vous ne savez pas quel port et quel protocole une application + particulière utilise, regardez ici.

    + +

    Important: Je ne vous recommande pas de permettre +le telnet depuis ou vers Internet car il utilise du texte en clair (même + pour le login et le mot de passe!). Si vous voulez un accès au shell + sur votre firewall depuis Internet, utilisez SSH :

    +
    -
    +
    - - - + + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - - - + + + +
    +

    ACTION

    -     		+

    SOURCE

    -     		+

    DESTINATION

    -     		+

    PROTOCOL

    -     		+

    PORT

    -     		+

    SOURCE PORT

    -     		+

    ORIGINAL ADDRESS

    -
    +

    ACCEPT

    -     		+

    net

    -     		+

    fw

    -     		+

    tcp

    -     		+

    22

    -     		+

     

    -     		+

     

    -
    -
    +
    - +

    -     Maintenant éditez votre fichier /etc/shorewall/rules -pour ajouter ou supprimer les connexions voulues.

    - +     Maintenant éditez votre fichier /etc/shorewall/rules + pour ajouter ou supprimer les connexions voulues.

    +

    Lancer et Arrêter votre Firewall

    - +

    Arrow -     La  procédure d'installation - configure votre système pour lancer Shorewall au boot du système, -mais pour les débutants sous Shorewall version 1.3.9, le lancement -est désactivé tant que la configuration n' est pas finie. Une -fois la configuration de votre firewall achevée, vous pouvez permettre -le lancement de Shorewall en enlevant le fichier /etc/shorewall/startup_disabled.

    - -

    IMPORTANT: Les utilisateurs des -paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.

    - -

    Le firewall est lancé en utilisant la commande "shorewall -start" et stoppé avec "shorewall stop". Lorsque le firewall est stoppé, -le routage est permis sur les hôtes qui sont dans le fichier/etc/shorewall/routestopped. Un -firewall fonctionnant peut être relancé en utilisant la commande -"shorewall restart". Si vous voulez enlever toutes les traces de Shorewall -dans votre configuration de Netfilter, utilisez "shorewall clear".

    - +     La  procédure d'installation + configure votre système pour lancer Shorewall au boot du système, + mais pour les débutants sous Shorewall version 1.3.9, le lancement + est désactivé tant que la configuration n' est pas finie. +Une fois la configuration de votre firewall achevée, vous pouvez +permettre le lancement de Shorewall en enlevant le fichier /etc/shorewall/startup_disabled.

    + +

    IMPORTANT: Les utilisateurs +des paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.

    + +

    Le firewall est lancé en utilisant la commande "shorewall + start" et stoppé avec "shorewall stop". Lorsque le firewall est stoppé, + le routage est permis sur les hôtes qui sont dans le fichier/etc/shorewall/routestopped. Un + firewall fonctionnant peut être relancé en utilisant la commande + "shorewall restart". Si vous voulez enlever toutes les traces de Shorewall + dans votre configuration de Netfilter, utilisez "shorewall clear".

    +

    -     Les exemples (two-interface) supposent que vous voulez -permettre le routage depuis ou vers eth1 (le réseau local) lorsque -Shorewall est stoppé. Si votre réseau local n' est pas connecté -à eth1 ou si vous voulez permettre l'accès depuis ou -vers d'autres hôtes, changez /etc/shorewall/routestopped en conséquence.

    - -

    ATTENTION: Si vous êtes connecté à -votre firewall depuis Internet, n'essayez pas la commande "shorewall stop" -tant que vous n'avez pas ajouté une entrée pour votre adresse -IP depuis laquelle vous êtes connecté dans/etc/shorewall/routestopped. De -plus, je ne vous recommande pas d'utiliser "shorewall restart"; il est mieux -de créer une configuration +     Les exemples (two-interface) supposent que vous voulez + permettre le routage depuis ou vers eth1 (le réseau local) +lorsque Shorewall est stoppé. Si votre réseau local n' est +pas connecté à eth1 ou si vous voulez permettre l'accès +depuis ou vers d'autres hôtes, changez /etc/shorewall/routestopped +en conséquence.

    + +

    ATTENTION: Si vous êtes connecté à + votre firewall depuis Internet, n'essayez pas la commande "shorewall stop" + tant que vous n'avez pas ajouté une entrée pour votre adresse + IP depuis laquelle vous êtes connecté dans/etc/shorewall/routestopped. De + plus, je ne vous recommande pas d'utiliser "shorewall restart"; il est mieux + de créer une configuration alternative et de l'essayer en utilisant la commande"shorewall try".

    - +

    Last updated 12/20/2002 - Tom Eastep

    - -

    Copyright 2002 Thomas -M. Eastep

    -
    -
    -
    -
    -
    -
    -
    + +

    Copyright 2002 Thomas + M. Eastep

    +
    +
    +
    +
    +
    +
    +
    +


    diff --git a/STABLE/documentation/upgrade_issues.htm b/STABLE/documentation/upgrade_issues.htm index bce12679d..3d7fe7683 100644 --- a/STABLE/documentation/upgrade_issues.htm +++ b/STABLE/documentation/upgrade_issues.htm @@ -1,441 +1,471 @@ - + Upgrade Issues - + - + - + - + - - - + + - - - + + + +
    - + bgcolor="#3366ff" height="90"> +
    +

    Upgrade Issues

    -
    - +

    For upgrade instructions see the Install/Upgrade page.
    -

    - -

    It is important that you read all of the sections on this page where the - version number mentioned in the section title is later than what you -are currently running.
    -

    - -

    In the descriptions that follows, the term group refers - to a particular network or subnetwork (which may be 0.0.0.0/0 or it may - be a host address) accessed through a particular interface.
    -

    - -

    Examples:
    -    
    -     eth0:0.0.0.0/0
    -     eth2:192.168.1.0/24
    -     eth3:192.0.2.123
    -

    - -

    You can use the "shorewall check" command to see the groups associated - with each of your zones.
    -

    - -

    - -

    Version >= 1.4.4

    - If you are upgrading from 1.4.3 and have set the LOGMARKER variable in -/etc/shorewall/shorewall.conf, then -you must set the new LOGFORMAT variable appropriately and remove your setting - of LOGMARKER
    -
    -

    Version 1.4.4
    -

    -If you have zone names that are 5 characters long, you may experience problems -starting Shorewall because the --log-prefix in a logging rule is too long. -Upgrade to Version 1.4.4a to fix this problem..
    - -

    Version >= 1.4.2

    - There are some cases where you may want to handle traffic from a particular - group to itself. While I personally think that such a setups are ridiculous, - there are two cases covered in this documentation where it can occur:
    - -
      -
    1. In FAQ #2.
      2. -
    2. When running Squid as a transparent - proxy in your local zone.
      3. - -
    - If you have either of these cases, you will want to review the current - documentation and change your configuration accordingly.
    - -

    Version >= 1.4.1

    - -
      -
    • Beginning with Version 1.4.1, traffic between groups in the -same zone is accepted by default. Previously, traffic from a zone to itself - was treated just like any other traffic; any matching rules were applied - followed by enforcement of the appropriate policy. With 1.4.1 and later - versions, unless you have explicit rules for traffic from Z to Z or you - have an explicit Z to Z policy (where "Z" is some zone) then traffic between - the groups in zone Z will be accepted. If you do have one or more explicit - rules for Z to Z or if you have an explicit Z to Z policy then the behavior - is as it was in prior versions.
      • - -
    - -
    -
      -
    1. If you have a Z Z ACCEPT policy for a zone to allow traffic - between two interfaces to the same zone, that policy can be removed and - traffic between the interfaces will traverse fewer rules than previously.
      2. -
    2. If you have a Z Z DROP or Z Z REJECT policy or you have Z->Z - rules then your configuration should not require any change.
      3. -
    3. If you are currently relying on a implicit policy (one that - has "all" in either the SOURCE or DESTINATION column) to prevent traffic - between two interfaces to a zone Z and you have no rules for Z->Z then - you should add an explicit DROP or REJECT policy for Z to Z.
      -
      4. - -
    -
    - -
      -
    • Sometimes, you want two separate zones on one interface but -you don't want Shorewall to set up any infrastructure to handle traffic -between them.
      • - -
    - -
    Example:
    - -
    - 
    /etc/shorewall/zones

    z1	Zone1	The first Zone
    z2	Zone2	The secont Zone

    /etc/shorewall/interfaces

    z2	eth1	192.168.1.255

    /etc/shorewall/hosts

    z1	eth1:192.168.1.3
    -
    - Here, zone z1 is nested in zone z2 and the firewall is not going to - be involved in any traffic between these two zones. Beginning with Shorewall - 1.4.1, you can prevent Shorewall from setting up any infrastructure to handle - traffic between z1 and z2 by using the new NONE policy:
    - -
    - 
    /etc/shorewall/policy
    z1	z2	NONE
    z2	z1	NONE
    -
    - Note that NONE policies are generally used in pairs unless there is - asymetric routing where only the traffic on one direction flows through - the firewall and you are using a NONE polciy in the other direction. 
    +

    -

    Version 1.4.1
    -

    +

    It is important that you read all of the sections on this page where the + version number mentioned in the section title is later than what you + are currently running.
    +

    + +

    In the descriptions that follows, the term group refers + to a particular network or subnetwork (which may be 0.0.0.0/0 or it may + be a host address) accessed through a particular interface.
    +

    + +

    Examples:
    +    
    +     eth0:0.0.0.0/0
    +     eth2:192.168.1.0/24
    +     eth3:192.0.2.123
    +

    + +

    You can use the "shorewall check" command to see the groups associated + with each of your zones.
    +

    + +

    + +

    Version >= 1.4.6

    + +
      +
    • The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed +from shorewall.conf. These capabilities are now automatically detected by +Shorewall.
      • +
    • An undocumented feature previously allowed entries in the host +file as follows:
      +
      + zone    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 to allow +entries of the following format:
      +
      + zone   eth1:192.168.1.0/24,192.168.2.0/24
      +
      • + +
    + +

    Version >= 1.4.4

    + If you are upgrading from 1.4.3 and have set the LOGMARKER variable +in /etc/shorewall/shorewall.conf, then +you must set the new LOGFORMAT variable appropriately and remove your setting + of LOGMARKER
    +
    +

    Version 1.4.4
    +

    + If you have zone names that are 5 characters long, you may experience +problems starting Shorewall because the --log-prefix in a logging rule +is too long. Upgrade to Version 1.4.4a to fix this problem..
    + +

    Version >= 1.4.2

    + There are some cases where you may want to handle traffic from a particular + group to itself. While I personally think that such a setups are ridiculous, + there are two cases covered in this documentation where it can occur:
    + +
      +
    1. In FAQ #2.
      2. +
    2. When running Squid as a +transparent proxy in your local zone.
      3. + +
    + If you have either of these cases, you will want to review the current + documentation and change your configuration accordingly.
    + +

    Version >= 1.4.1

    +
      -
    • In Version 1.4.1, Shorewall will never create rules to deal - with traffic from a given group back to itself. The multi interface - option is no longer available so if you want to route traffic between two - subnetworks on the same interface then I recommend that you upgrade to Version - 1.4.2 and use the 'routeback' interface or host option. 
      • - +
    • Beginning with Version 1.4.1, traffic between groups in +the same zone is accepted by default. Previously, traffic from a zone +to itself was treated just like any other traffic; any matching rules +were applied followed by enforcement of the appropriate policy. With 1.4.1 +and later versions, unless you have explicit rules for traffic from Z +to Z or you have an explicit Z to Z policy (where "Z" is some zone) then +traffic between the groups in zone Z will be accepted. If you do have one +or more explicit rules for Z to Z or if you have an explicit Z to Z policy +then the behavior is as it was in prior versions.
      • +
    - + +
    +
      +
    1. If you have a Z Z ACCEPT policy for a zone to allow traffic + between two interfaces to the same zone, that policy can be removed +and traffic between the interfaces will traverse fewer rules than previously.
      2. +
    2. If you have a Z Z DROP or Z Z REJECT policy or you have + Z->Z rules then your configuration should not require any change.
      3. +
    3. If you are currently relying on a implicit policy (one +that has "all" in either the SOURCE or DESTINATION column) to prevent +traffic between two interfaces to a zone Z and you have no rules for +Z->Z then you should add an explicit DROP or REJECT policy for Z to +Z.
      +
      4. + +
    +
    + +
      +
    • Sometimes, you want two separate zones on one interface but + you don't want Shorewall to set up any infrastructure to handle traffic + between them.
      • + +
    + +
    Example:
    + +
    + 
    /etc/shorewall/zones

    z1	Zone1	The first Zone
    z2	Zone2	The secont Zone

    /etc/shorewall/interfaces

    z2	eth1	192.168.1.255

    /etc/shorewall/hosts

    z1	eth1:192.168.1.3
    +
    + Here, zone z1 is nested in zone z2 and the firewall is not going + to be involved in any traffic between these two zones. Beginning with +Shorewall 1.4.1, you can prevent Shorewall from setting up any infrastructure +to handle traffic between z1 and z2 by using the new NONE policy:
    + +
    + 
    /etc/shorewall/policy
    z1	z2	NONE
    z2	z1	NONE
    +
    + Note that NONE policies are generally used in pairs unless there + is asymetric routing where only the traffic on one direction flows through + the firewall and you are using a NONE polciy in the other direction. 
    + +

    Version 1.4.1
    +

    + +
      +
    • In Version 1.4.1, Shorewall will never create rules to + deal with traffic from a given group back to itself. The multi + interface option is no longer available so if you want to route traffic +between two subnetworks on the same interface then I recommend that you +upgrade to Version 1.4.2 and use the 'routeback' interface or host option. 
      • + +
    +

    Version >= 1.4.0

    - IMPORTANT: Shorewall >=1.4.0 requires the -iproute package ('ip' utility).
    + IMPORTANT: Shorewall >=1.4.0 requires the + iproute package ('ip' utility).
    +
    + Note: Unfortunately, some distributions call this package + iproute2 which will cause the upgrade of Shorewall to fail with the +diagnostic:
    +
    +      error: failed dependencies:iproute is needed by shorewall-1.4.0-1
    - Note: Unfortunately, some distributions call this package -iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:
    -
    -      error: failed dependencies:iproute is needed by shorewall-1.4.0-1 -
    -
    - This may be worked around by using the --nodeps option of rpm (rpm - -Uvh --nodeps <shorewall rpm>).
    -
    - If you are upgrading from a version < 1.4.0, then:
    - +
    + This may be worked around by using the --nodeps option of rpm + (rpm -Uvh --nodeps <shorewall rpm>).
    +
    + If you are upgrading from a version < 1.4.0, then:
    +
      -
    • The noping and forwardping interface options - are no longer supported nor is the FORWARDPING option in shorewall.conf. - ICMP echo-request (ping) packets are treated just like any other connection - request and are subject to rules and policies.
      • -
    • Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate a Shorewall error at startup - (they always have produced warnings in iptables).
      • -
    • The MERGE_HOSTS variable has been removed from shorewall.conf. - Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone - contents are determined by BOTH the interfaces and hosts files when there - are entries for the zone in both files.
      • -
    • The routestopped option in the interfaces and -hosts file has been eliminated; use entries in the routestopped file -instead.
      • -
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules -is no longer accepted; you must convert to using the new syntax.
      • -
    • The ALLOWRELATED variable in shorewall.conf - is no longer supported. Shorewall 1.4 behavior is the same as 1.3 +
    • The noping and forwardping interface + options are no longer supported nor is the FORWARDPING option + in shorewall.conf. ICMP echo-request (ping) packets are treated just + like any other connection request and are subject to rules and policies.
      • +
    • Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate a Shorewall error at startup + (they always have produced warnings in iptables).
      • +
    • The MERGE_HOSTS variable has been removed from shorewall.conf. + Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone + contents are determined by BOTH the interfaces and hosts files when + there are entries for the zone in both files.
      • +
    • The routestopped option in the interfaces +and hosts file has been eliminated; use entries in the routestopped +file instead.
      • +
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules + is no longer accepted; you must convert to using the new syntax.
      • +
    • The ALLOWRELATED variable in shorewall.conf + is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      • -
    • Late-arriving DNS replies are now dropped -by default; there is no need for your own /etc/shorewall/common file -simply to avoid logging these packets.
      • -
    • The 'firewall', 'functions' and 'version' -file have been moved to /usr/share/shorewall.
      • -
    • The icmp.def file has been removed. If you -include it from /etc/shorewall/icmpdef, you will need to modify that -file.
      • - +
    • Late-arriving DNS replies are now dropped + by default; there is no need for your own /etc/shorewall/common file + simply to avoid logging these packets.
      • +
    • The 'firewall', 'functions' and 'version' + file have been moved to /usr/share/shorewall.
      • +
    • The icmp.def file has been removed. If you + include it from /etc/shorewall/icmpdef, you will need to modify that + file.
      • +
        - +
      -
    • If you followed the advice in FAQ #2 and call find_interface_address - in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
      -
      • - +
    • If you followed the advice in FAQ #2 and call find_interface_address + in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
      +
      • +
    - +
      - +
    - +

    Version 1.4.0

    - +
      -
    • The 'multi' interface option is no longer supported. -  Shorewall will generate rules for sending packets back out the same - interface that they arrived on in two cases:
      • - +
    • The 'multi' interface option is no longer supported. +  Shorewall will generate rules for sending packets back out the same + interface that they arrived on in two cases:
      • +
    - -
    + +
      -
    • There is an explicit policy for the source zone to -or from the destination zone. An explicit policy names both zones and -does not use the 'all' reserved word.
      • - +
    • There is an explicit policy for the source zone +to or from the destination zone. An explicit policy names both zones +and does not use the 'all' reserved word.
      • +
    - +
      -
    • There are one or more rules for traffic for the source zone - to or from the destination zone including rules that use the 'all' reserved - word. Exception: if the source zone and destination zone are the same - then the rule must be explicit - it must name the zone in both the SOURCE - and DESTINATION columns.
      • - +
    • There are one or more rules for traffic for the source +zone to or from the destination zone including rules that use the 'all' +reserved word. Exception: if the source zone and destination zone are +the same then the rule must be explicit - it must name the zone in both +the SOURCE and DESTINATION columns.
      • +
    -
    - +
    +

    Version >= 1.3.14

    - -      Beginning in version 1.3.14, Shorewall treats entries - in /etc/shorewall/masq differently. - The change involves entries with an interface name in the SUBNET - (second) column:
    - +      Beginning in version 1.3.14, Shorewall treats entries + in /etc/shorewall/masq differently. + The change involves entries with an interface name in the SUBNET + (second) column:
    +
      -
    • Prior to 1.3.14, Shorewall would detect the FIRST -subnet on the interface (as shown by "ip addr show interface") -and would masquerade traffic from that subnet. Any other subnets that -routed through eth1 needed their own entry in /etc/shorewall/masq to -be masqueraded or to have SNAT applied.
      • -
    • Beginning with Shorewall 1.3.14, Shorewall uses the - firewall's routing table to determine ALL subnets routed through -the named interface. Traffic originating in ANY of those subnets -is masqueraded or has SNAT applied.
      • - +
    • Prior to 1.3.14, Shorewall would detect the FIRST + subnet on the interface (as shown by "ip addr show interface") + and would masquerade traffic from that subnet. Any other subnets that + routed through eth1 needed their own entry in /etc/shorewall/masq to + be masqueraded or to have SNAT applied.
      • +
    • Beginning with Shorewall 1.3.14, Shorewall uses +the firewall's routing table to determine ALL subnets routed through +the named interface. Traffic originating in ANY of those subnets is +masqueraded or has SNAT applied.
      • +
    - You will need to make a change to your configuration if:
    - + You will need to make a change to your configuration +if:
    +
      -
    1. You have one or more entries in /etc/shorewall/masq - with an interface name in the SUBNET (second) column; and
      2. -
    2. That interface connects to more than one subnetwork.
      3. - +
    3. You have one or more entries in /etc/shorewall/masq + with an interface name in the SUBNET (second) column; and
      4. +
    4. That interface connects to more than one subnetwork.
      5. +
    - Two examples:
    -
    -  Example 1 -- Suppose that your current config is -as follows:
    -   
    - + Two examples:
    +
    +  Example 1 -- Suppose that your current config +is as follows:
    +   
    + 
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    - -
    In this case, the second entry in /etc/shorewall/masq is no longer - required.
    -
    - Example 2-- What if your current configuration is -like this?
    - + +
    In this case, the second entry in /etc/shorewall/masq is no longer + required.
    +
    + Example 2-- What if your current configuration +is like this?
    + 
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    - -
    In this case, you would want to change the entry in /etc/shorewall/masq - to:
    -
    - + +
    In this case, you would want to change the entry in /etc/shorewall/masq + to:
    +
    + 
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - -     Version 1.3.14 also introduced simplified ICMP echo-request - (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf - is used to specify that the old (pre-1.3.14) ping handling is to -be used (If the option is not set in your /etc/shorewall/shorewall.conf - then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting -the old handling indefinitely so I urge current users to migrate to using -the new handling as soon as possible. See the 'Ping' -handling documentation for details.
    - +     Version 1.3.14 also introduced simplified ICMP echo-request + (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf + is used to specify that the old (pre-1.3.14) ping handling is to +be used (If the option is not set in your /etc/shorewall/shorewall.conf + then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting +the old handling indefinitely so I urge current users to migrate to using + the new handling as soon as possible. See the 'Ping' + handling documentation for details.
    +

    Version 1.3.10

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

    Version >= 1.3.9

    - The 'functions' file has moved to /usr/lib/shorewall/functions. - If you have an application that uses functions from that file, your - application will need to be changed to reflect this change of location.
    - + The 'functions' file has moved to /usr/lib/shorewall/functions. + If you have an application that uses functions from that file, your + application will need to be changed to reflect this change of location.
    +

    Version >= 1.3.8

    - -

    If you have a pair of firewall systems configured for failover - or if you have asymmetric routing, you will need to modify + +

    If you have a pair of firewall systems configured for failover + or if you have asymmetric routing, you will need to modify your firewall setup slightly under Shorewall - versions >= 1.3.8. Beginning with version 1.3.8, - you must set NEWNOTSYN=Yes in your - /etc/shorewall/shorewall.conf file.

    - + versions >= 1.3.8. Beginning with version 1.3.8, + you must set NEWNOTSYN=Yes in your + /etc/shorewall/shorewall.conf file.

    +

    Version >= 1.3.7

    - -

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf - will need to include the following - rules in their /etc/shorewall/icmpdef file (creating this - file if necessary):

    - + +

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf + will need to include the following + rules in their /etc/shorewall/icmpdef file (creating this + file if necessary):

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

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" - command from that file since the icmp.def file is now empty.

    - + +

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" + command from that file since the icmp.def file is now empty.

    +

    Upgrading Bering to Shorewall >= 1.3.3

    - +

    To properly upgrade with Shorewall version 1.3.3 and later:

    - +
      -
    1. Be sure you have - a backup -- you will need to transcribe - any Shorewall configuration changes - that you have made to the new configuration.
      2. -
    2. Replace the shorwall.lrp - package provided on the Bering -floppy with the later one. If you did - not obtain the later version from Jacques's site, see additional - instructions below.
      3. -
    3. Edit the /var/lib/lrpkg/root.exclude.list - file and remove the /var/lib/shorewall - entry if present. Then do not +
    4. Be sure you +have a backup -- you will need +to transcribe any Shorewall configuration + changes that you have made to the new + configuration.
      5. +
    5. Replace the +shorwall.lrp package provided on + the Bering floppy with the later one. If you did + not obtain the later version from Jacques's site, + see additional instructions below.
      6. +
    6. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall + entry if present. Then do not forget to backup root.lrp !
      7. - +
    - -

    The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions for setting up a two-interface - firewall plus you also need to add the following two Bering-specific - rules to /etc/shorewall/rules:

    - -
    + +

    The .lrp that I release isn't set up for a two-interface firewall like + Jacques's. You need to follow the instructions for setting up a two-interface + firewall plus you also need to add the following two Bering-specific + rules to /etc/shorewall/rules:

    + +
    # Bering specific rules:
    # allow loc to fw udp/53 for dnscache to work
    # allow loc to fw tcp/80 for weblet to work
    #
    ACCEPT loc fw udp 53
    ACCEPT loc fw tcp 80
    -
    - +
    +

    Version 1.3.6 and 1.3.7

    - -

    If you have a pair of firewall systems configured for - failover or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall versions 1.3.6 - and 1.3.7

    - + +

    If you have a pair of firewall systems configured for + failover or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall versions +1.3.6 and 1.3.7

    +
      -
    1. -

      Create the file /etc/shorewall/newnotsyn and in it add - the following rule
      -
      - run_iptables -A newnotsyn - -j RETURN # So that the connection tracking table can -be rebuilt
      -                                     # from - non-SYN packets after takeover.
      -  

      -
      2. -
    2. -

      Create /etc/shorewall/common (if you don't already - have that file) and include the following:
      -
      - run_iptables -A common - -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept -Acks to rebuild connection
      -                                                                     - #tracking table.
      - . /etc/shorewall/common.def

      -
      3. - +
    3. + +

      Create the file /etc/shorewall/newnotsyn and in it add + the following rule
      +
      + run_iptables -A +newnotsyn -j RETURN # So that the connection tracking +table can be rebuilt
      +                                     +# from non-SYN packets after takeover.
      +  

      +
      4. +
    4. + +

      Create /etc/shorewall/common (if you don't already + have that file) and include the following:
      +
      + run_iptables -A +common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT +#Accept Acks to rebuild connection
      +                                                                     + #tracking table.
      + . /etc/shorewall/common.def

      +
      5. +
    - +

    Versions >= 1.3.5

    - -

    Some forms of pre-1.3.0 rules file syntax are no longer - supported.

    - + +

    Some forms of pre-1.3.0 rules file syntax are no longer + supported.

    +

    Example 1:

    - -
    + +
    	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
    -
    - +
    +

    Must be replaced with:

    - -
    + +
    	DNAT	net	loc:192.168.1.12:22	tcp	11111
    -
    - -
    +
    + +

    Example 2:

    -
    - -
    +
    + +
    	ACCEPT	loc	fw::3128	tcp	80	-	all
    -
    - -
    +
    + +

    Must be replaced with:

    -
    - -
    +
    + +
    	REDIRECT	loc	3128	tcp	80
    -
    - +
    +

    Version >= 1.3.2

    - -

    The functions and versions files together with the 'firewall' - symbolic link have moved from /etc/shorewall to /var/lib/shorewall. - If you have applications that access these files, those applications - should be modified accordingly.

    - -

    Last updated 5/27/2003 - Tom Eastep -

    - -

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

    + +

    The functions and versions files together with the 'firewall' + symbolic link have moved from /etc/shorewall to /var/lib/shorewall. + If you have applications that access these files, those + applications should be modified accordingly.

    + +

    Last updated 6/29/2003 - Tom +Eastep

    + +

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

    +
    +
    +
    diff --git a/STABLE/documentation/useful_links.html b/STABLE/documentation/useful_links.html index 205276198..b55737d14 100644 --- a/STABLE/documentation/useful_links.html +++ b/STABLE/documentation/useful_links.html @@ -2,61 +2,62 @@ Useful Links - + - + - + - - - + + - - - + +
    + + + +
    + bgcolor="#3366ff" height="90"> +

    Useful Links
    -

    -
    -
    -     
    - +     
    +

    NetFilter Site: http://www.netfilter.orgNetfilter Logo -

    - + +

    Linux Advanced Routing and Traffic Control Howto: http://ds9a.nl/lartc

    - +

    Iproute Downloads: ftp://ftp.inr.ac.ru/ip-routing

    - +

    LEAF Site: http://leaf-project.orgLeaf Logo -

    - + +

    Bering LEAF Distribution: http://leaf.sourceforge.net/devel/jnilo

    - +

    Debian apt-get sources for Shorewall: http://security.dsi.unimi.it/~lorenzo/debian.htmlOpen Logo - Debian Logo -
    -

    -
    - Last updated 9/16/2002 - Tom Eastep - -

    Copyright +
    + +
    + Last updated 9/16/2002 - Tom Eastep + +

    Copyright © 2001, 2002 Thomas M. Eastep.

    +



    diff --git a/STABLE/documentation/whitelisting_under_shorewall.htm b/STABLE/documentation/whitelisting_under_shorewall.htm index dac9ebe21..5dd7f367e 100644 --- a/STABLE/documentation/whitelisting_under_shorewall.htm +++ b/STABLE/documentation/whitelisting_under_shorewall.htm @@ -1,326 +1,309 @@ - + - + - + - + Whitelisting under Shorewall - + - - - + + - - - + + + +
    + id="AutoNumber1" bgcolor="#3366ff" height="90"> +

    Whitelisting under Shorewall

    -
    - -

    For a brief time, the 1.2 version of Shorewall supported an - /etc/shorewall/whitelist file. This file was intended to contain a list of -IP addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist -file was implemented as a stop-gap measure until the facilities necessary -for implementing white lists using zones was in place. As of Version 1.3 + +

    For a brief time, the 1.2 version of Shorewall supported +an /etc/shorewall/whitelist file. This file was intended to contain a list +of IP addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist +file was implemented as a stop-gap measure until the facilities necessary +for implementing white lists using zones was in place. As of Version 1.3 RC1, those facilities were available.

    - -

    White lists are most often used to give special privileges -to a set  of hosts within an organization. Let us suppose that we have the + +

    White lists are most often used to give special privileges +to a set  of hosts within an organization. Let us suppose that we have the following environment:

    - +
      -
    • A firewall with three interfaces -- one to the internet, one to -a local network and one to a DMZ.
      • -
    • The local network uses SNAT to the internet and is comprised of -the class B network 10.10.0.0/16 (Note: While this example uses an RFC 1918 - local network, the technique described here in no way depends on that or -on SNAT. It may be used with Proxy ARP, Subnet Routing, Static NAT, etc.).
      • -
    • The network operations staff have workstations with IP addresses +
    • A firewall with three interfaces -- one to the internet, one +to a local network and one to a DMZ.
      • +
    • The local network uses SNAT to the internet and is comprised +of the class B network 10.10.0.0/16 (Note: While this example uses an RFC +1918 local network, the technique described here in no way depends on +that or on SNAT. It may be used with Proxy ARP, Subnet Routing, Static +NAT, etc.).
      • +
    • The network operations staff have workstations with IP addresses in the class C network 10.10.10.0/24
      • -
    • We want the network operations staff to have full access to all +
    • We want the network operations staff to have full access to all other hosts.
      • -
    • We want the network operations staff to bypass the transparent - HTTP proxy running on our firewall.
      • - +
    • We want the network operations staff to bypass the transparent +HTTP proxy running on our firewall.
      • +
    - -

    The basic approach will be that we will place the operations - staff's class C in its own zone called ops. Here are the appropriate + +

    The basic approach will be that we will place the operations + staff's class C in its own zone called ops. Here are the appropriate configuration files:

    - +

    Zone File

    - -
    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE DISPLAY COMMENTS
    netNetInternet
    opsOperationsOperations Staff's Class C
    locLocalLocal Class B
    dmzDMZDemilitarized zone
    -
    - -

    The ops zone has been added to the standard 3-zone zones file -- -since ops is a sub-zone of loc, we list it BEFORE loc.

    - -

    Interfaces File

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0<whatever><options>
    dmzeth1<whatever>
    -
    -eth210.10.255.255 
    -
    - -

    Because eth2 interfaces to two zones (ops and loc), -we don't specify a zone for it here.

    - -

    Hosts File

    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ZONE HOST(S) OPTIONS
    opseth2:10.10.10.0/24
    -
    loceth2:0.0.0.0/0 
    -
    - -

    Here we define the ops and loc zones. When Shorewall is -stopped, only the hosts in the ops zone will be allowed to access the - firewall and the DMZ. I use 0.0.0.0/0 to define the loc zone rather -than 10.10.0.0/16 so that the limited broadcast address (255.255.255.255) -falls into that zone. If I used 10.10.0.0/16 then I would have to have a -separate entry for that special address.

    - -

    Policy File

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    opsallACCEPT  
    allopsCONTINUE  
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - -

    Two entries for ops have been added to the standard 3-zone policy -file.

    - -

    Rules File

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    REDIRECTloc!ops3128tcphttp  
    ...      
    -
    - -

    This is the rule that transparently redirects web traffic to the transparent - proxy running on the firewall. The SOURCE column explicitly excludes the -ops zone from the rule.

    -

    Routestopped File

    - -
    - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + +
    INTERFACE
    -     		HOST(S)
    eth1
    -
    -
    eth2
    -     		10.10.10.0/24
    ZONE DISPLAY COMMENTS
    netNetInternet
    opsOperationsOperations Staff's Class C
    locLocalLocal Class B
    dmzDMZDemilitarized zone
    -
    -
    - - - - -

    Updated 2/18/2003 - Tom Eastep +

    + +

    The ops zone has been added to the standard 3-zone zones file -- +since ops is a sub-zone of loc, we list it BEFORE loc.

    + +

    Interfaces File

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0<whatever><options>
    dmzeth1<whatever>
    +
    -eth210.10.255.255 
    +
    + +

    Because eth2 interfaces to two zones (ops and loc), +we don't specify a zone for it here.

    + +

    Hosts File

    + +
    + + + + + + + + + + + + + + + + + + + + +
    ZONE HOST(S) OPTIONS
    opseth2:10.10.10.0/24
    +
    loceth2:0.0.0.0/0 
    +
    + +

    Here we define the ops and loc zones. When Shorewall is stopped, +only the hosts in the ops zone will be allowed to access the firewall +and the DMZ. I use 0.0.0.0/0 to define the loc zone rather than 10.10.0.0/16 +so that the limited broadcast address (255.255.255.255) falls into that +zone. If I used 10.10.0.0/16 then I would have to have a separate entry for + that special address.

    + +

    Policy File

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    opsallACCEPT  
    allopsCONTINUE  
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    +
    + +

    Two entries for ops have been added to the standard 3-zone policy +file.

    + +

    Rules File

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    REDIRECTloc!ops3128tcphttp  
    ...      
    +
    + +

    This is the rule that transparently redirects web traffic to the transparent + proxy running on the firewall. The SOURCE column explicitly excludes the +ops zone from the rule.

    + +

    Routestopped File

    + +
    + + + + + + + + + + + + + + + + +
    INTERFACE
    +     		HOST(S)
    eth1
    +
    +
    eth2
    +     		10.10.10.0/24
    +
    +
    + +

    Updated 2/18/2003 - Tom Eastep

    - - - -

    Copyright + +

    Copyright © 2002, 2003Thomas M. Eastep.

    - - -
    +
    +

    diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index 14ffb549a..bae84ca68 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.4.5 +VERSION=1.4.6 usage() # $1 = exit status { diff --git a/STABLE/firewall b/STABLE/firewall index 513d7b43c..53212a90c 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -1866,7 +1866,7 @@ add_nat_rule() { log_rule $loglevel $chain $logtarget -t nat fi - addnatrule $chain -j $target1 + addnatrule $chain $proto -j $target1 else for adr in `separate_list $addr`; do run_iptables2 -t nat -A OUTPUT $proto $sports -d $adr \ @@ -1899,7 +1899,7 @@ add_nat_rule() { log_rule $loglevel $chain $logtarget -t nat -d `fix_bang $adr` fi - addnatrule $chain -d $adr -j $target1 + addnatrule $chain $proto -d $adr -j $target1 done else for adr in `separate_list $addr`; do @@ -2218,11 +2218,11 @@ process_rule() # $1 = target fatal_error "Empty source zone or qualifier: rule \"$rule\"" fi - if [ "$clientzone" = "${clientzone%\!*}" ]; then + if [ "$clientzone" = "${clientzone%!*}" ]; then excludezones= else - excludezones="${clientzone#*\!}" - clientzone="${clientzone%\!*}" + excludezones="${clientzone#*!}" + clientzone="${clientzone%!*}" [ "$logtarget" = DNAT ] || [ "$logtarget" = REDIRECT ] ||\ fatal_error "Exclude list only allowed with DNAT or REDIRECT" diff --git a/STABLE/functions b/STABLE/functions index 621a7cf38..3fc8bc5d0 100644 --- a/STABLE/functions +++ b/STABLE/functions @@ -219,3 +219,164 @@ strip_file() # $1 = Base Name of the file, $2 = Full Name of File (optional) > $TMP_DIR/$1 fi } + +# +# Note: The following set of IP address manipulation functions have anomalous +# behavior when the shell only supports 32-bit signed arithmatic and +# the IP address is 128.0.0.0 or 128.0.0.1. +# +# +# So that emacs doesn't get lost, we use $LEFTSHIFT rather than << +# +LEFTSHIFT='<<' + +# +# Convert an IP address in dot quad format to an integer +# +decodeaddr() { + local x + local temp=0 + local ifs=$IFS + + IFS=. + + for x in $1; do + temp=$(( $(( $temp $LEFTSHIFT 8 )) | $x )) + done + + echo $temp + + IFS=$ifs +} + +# +# convert an integer to dot quad format +# +encodeaddr() { + addr=$1 + local x + local y=$(($addr & 255)) + + for x in 1 2 3 ; do + addr=$(($addr >> 8)) + y=$(($addr & 255)).$y + done + + echo $y +} + +# +# Enumerate the members of an IP range -- When using a shell supporting only +# 32-bit signed arithmetic, the range cannot span 128.0.0.0. +# +ip_range() { + local first last l x y z vlsm + + case $1 in + [0-9]*.*.*.*-*.*.*.*) + ;; + *) + echo $1 + return + ;; + esac + + first=`decodeaddr ${1%-*}` + last=`decodeaddr ${1#*-}` + + if [ $first -gt $last ]; then + fatal_error "Invalid IP address range: $1" + fi + + l=$(( $last + 1 )) + + while [ $first -le $last ]; do + vlsm= + x=31 + y=2 + z=1 + + while [ $(( $first % $y )) -eq 0 -a $(( $first + $y )) -le $l ]; do + vlsm=/$x + x=$(( $x - 1 )) + z=$y + y=$(( $y * 2 )) + done + + echo `encodeaddr $first`$vlsm + first=$(($first + $z)) + done +} + +# +# Netmask from CIDR +# +ip_netmask() { + local vlsm=${1#*/} + + [ $vlsm -eq 0 ] && echo 0 || echo $(( -1 $LEFTSHIFT $(( 32 - $vlsm )) )) +} + +# +# Network address from CIDR +# +ip_network() { + local decodedaddr=`decodeaddr ${1%/*}` + local netmask=`ip_netmask $1` + + echo `encodeaddr $(($decodedaddr & $netmask))` +} + +# +# The following hack is supplied to compensate for the fact that many of +# the popular light-weight Bourne shell derivatives don't support XOR ("^"). +# +# Note: 2147483647 = 0x7fffffff + +ip_broadcast() { + local x=$(( ${1#*/} - 1 )) + + [ $x -eq -1 ] && echo -1 || echo $(( 2147483647 >> $x )) +} + +# +# Calculate broadcast address from CIDR +# +broadcastaddress() { + local decodedaddr=`decodeaddr ${1%/*}` + local netmask=`ip_netmask $1` + local broadcast=`ip_broadcast $1` + + echo `encodeaddr $(( $(($decodedaddr & $netmask)) | $broadcast ))` +} + +# +# Test for subnet membership +# +in_subnet() # $1 = IP address, $2 = CIDR network +{ + local netmask=`ip_netmask $2` + + test $(( `decodeaddr $1` & $netmask)) -eq $(( `decodeaddr ${2%/*}` & $netmask )) +} + +# +# Netmask to VLSM +# +ip_vlsm() { + local mask=`decodeaddr $1` + local vlsm=0 + local x=$(( 128 $LEFTSHIFT 24 )) + + while [ $(( $x & $mask )) -ne 0 ]; do + [ $mask -eq $x ] && mask=0 || mask=$(( $mask $LEFTSHIFT 1 )) # Don't Ask... + vlsm=$(($vlsm + 1)) + done + + if [ $(( $mask & 2147483647)) -ne 0 ]; then + echo "Invalid net mask: $1" >&2 + else + echo $vlsm + fi +} + diff --git a/STABLE/hosts b/STABLE/hosts index c38ae4a2e..a60b16bee 100644 --- a/STABLE/hosts +++ b/STABLE/hosts @@ -20,7 +20,7 @@ # ZONE - The name of a zone defined in /etc/shorewall/zones # # HOST(S) - The name of an interface followed by a colon (":") and -# either: +# a comma-separated list whose elements are either: # # a) The IP address of a host # b) A subnetwork in the form @@ -33,6 +33,7 @@ # # eth1:192.168.1.3 # eth2:192.168.2.0/24 +# eth3:192.168.2.0/24,192.168.3.1 # # OPTIONS - A comma-separated list of options. Currently-defined # options are: diff --git a/STABLE/install.sh b/STABLE/install.sh index a51dd999c..8cc393dff 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.4.5 +VERSION=1.4.6 usage() # $1 = exit status { diff --git a/STABLE/interfaces b/STABLE/interfaces index cfc0e2b0e..41c50e807 100644 --- a/STABLE/interfaces +++ b/STABLE/interfaces @@ -20,6 +20,10 @@ # an alias (e.g., eth0:0) here; see # http://www.shorewall.net/FAQ.htm#faq18 # +# You may specify wildcards here. For example, if you +# want to make an entry that applies to all PPP +# interfaces, use 'ppp+'. +# # DO NOT DEFINE THE LOOPBACK INTERFACE (lo) IN THIS FILE. # # BROADCAST The broadcast address for the subnetwork to which the @@ -89,6 +93,16 @@ # sub-networking as described at: # http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet # +# newnotsyn - TCP packets that don't have the SYN +# flag set and which are not part of an +# established connection will be accepted +# from this interface, even if +# NEWNOTSYN=No has been specified in +# /etc/shorewall/shorewall.conf. +# +# This option has no effect if +# NEWNOTSYN=Yes. +# # The order in which you list the options is not # significant but the list should have no embedded white # space. diff --git a/STABLE/masq b/STABLE/masq index 27826945c..c127c2ac8 100644 --- a/STABLE/masq +++ b/STABLE/masq @@ -42,12 +42,15 @@ # will automatically add this address to the # INTERFACE named in the first column. # -# WARNING: Do NOT specify ADD_SNAT_ALIASES=Yes if -# the address given in this column is the primary -# IP address for the interface in the INTERFACE -# column. +# You may also specify a range of up to 256 +# IP addresses if you want the SNAT address to +# be assigned from that range in a round-robin +# range by connection. The range is specified by +# -. # -# This column may not contain a DNS Name. +# Example: 206.124.146.177-206.124.146.180 +# +# This column may not contain DNS Names. # # Example 1: # diff --git a/STABLE/releasenotes.txt b/STABLE/releasenotes.txt index 670d034f7..0e2d14c7f 100644 --- a/STABLE/releasenotes.txt +++ b/STABLE/releasenotes.txt @@ -2,19 +2,180 @@ This is a minor release of Shorewall. Problems Corrected: -1) The command "shorewall debug try " now correctly traces - the attempt. +1) A problem seen on RH7.3 systems where Shorewall encountered start + errors when started using the "service" mechanism has been worked + around. -2) The INCLUDE directive now works properly in the zones file; - previously, INCLUDE in that file was ignored. +2) Where a list of IP addresses appears in the DEST column of a DNAT[-] + rule, Shorewall incorrectly created multiple DNAT rules in the nat + table (one for each element in the list). Shorewall now correctly + creates a single DNAT rule with multiple "--to-destination" clauses. -3) /etc/shorewall/routestopped records with an empty second column are no - longer ignored. +3) Corrected a problem in Beta 1 where DNS names containing a "-" were + mis-handled when they appeared in the DEST column of a rule. + +4) The handling of z1!z2 in the SOURCE column of DNAT and REDIRECT + rules has been corrected. + +5) The message "Adding rules for DHCP" is now suppressed if there are + no DHCP rules to add. + +Migration Issues: + +1) In earlier versions, an undocumented feature allowed entries in + the host file as follows: + + z eth1:192.168.1.0/24,eth2:192.168.2.0/24 + + This capability was never documented and has been removed in 1.4.6 + to allow entries of the following format: + + z eth1:192.168.1.0/24,192.168.2.0/24 + +2) The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been + removed from /etc/shorewall/shorewall.conf. These capabilities are + now automatically detected by Shorewall (see below). New Features: -1) The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now - contain a list of addresses. If the list begins with "!' then the - rule will take effect only if the original destination address in - the connection request does not match any of the addresses listed. +1) A 'newnotsyn' interface option has been added. This option may be + specified in /etc/shorewall/interfaces and overrides the setting + NEWNOTSYN=No for packets arriving on the associated interface. + +2) The means for specifying a range of IP addresses in + /etc/shorewall/masq to use for SNAT is now + documented. ADD_SNAT_ALIASES=Yes is enabled for address ranges. + +3) Shorewall can now add IP addresses to subnets other than the first + one on an interface. + +4) DNAT[-] rules may now be used to load balance (round-robin) over a + set of servers. Any number of servers may be specified in a range of + addresses given as - and multiple + ranges or individual servers may be specified in a comma-separated + list. + + Example: + + DNAT net loc:192.168.10.2-192.168.10.5,192.168.10.44 tcp 80 + +5) The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options + have been removed and have been replaced by code that detects + whether these capabilities are present in the current kernel. The + output of the start, restart and check commands have been enhanced + to report the outcome: + + Shorewall has detected the following iptables/netfilter capabilities: + NAT: Available + Packet Mangling: Available + Multi-port Match: Available + Verifying Configuration... + +6) Support for the Connection Tracking Match Extension has been + added. This extension is available in recent kernel/iptables + releases and allows for rules which match against elements in + netfilter's connection tracking table. + + Shorewall automatically detects the availability of this extension + and reports its availability in the output of the start, restart and + check commands. + + Shorewall has detected the following iptables/netfilter capabilities: + NAT: Available + Packet Mangling: Available + Multi-port Match: Available + Connection Tracking Match: Available + Verifying Configuration... + + If this extension is available, the ruleset generated by Shorewall + is changed in the following ways: + + a) To handle 'norfc1918' filtering, Shorewall will not create chains + in the mangle table but will rather do all 'norfc1918' filtering in + the filter table (rfc1918 chain). + + b) Recall that Shorewall DNAT rules generate two netfilter rules; + one in the nat table and one in the filter table. If the Connection + Tracking Match Extension is available, the rule in the filter table + is extended to check that the original destination address was the + same as specified (or defaulted to) in the DNAT rule. + +7) The shell used to interpret the firewall script + (/usr/share/shorewall/firewall) may now be specified using the + SHOREWALL_SHELL parameter in shorewall.conf. + +8) An 'ipcalc' command has been added to /sbin/shorewall. + + ipcalc [
    |
    / ] + + Examples: + + [root@wookie root]# shorewall ipcalc 192.168.1.0/24 + CIDR=192.168.1.0/24 + NETMASK=255.255.255.0 + NETWORK=192.168.1.0 + BROADCAST=192.168.1.255 + [root@wookie root]# + + [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0 + CIDR=192.168.1.0/24 + NETMASK=255.255.255.0 + NETWORK=192.168.1.0 + BROADCAST=192.168.1.255 + [root@wookie root]# + + Warning: + + If your shell only supports 32-bit signed arithmatic (ash or + dash), then the ipcalc command produces incorrect information for + IP addresses 128.0.0.0-1 and for /1 networks. Bash should produce + correct information for all valid IP addresses. + +9) An 'iprange' command has been added to /sbin/shorewall. + + iprange
    -
    + + This command decomposes a range of IP addressses into a list of + network and host addresses. The command can be useful if you need to + construct an efficient set of rules that accept connections from a + range of network addresses. + + Note: If your shell only supports 32-bit signed arithmetic (ash or + dash) then the range may not span 128.0.0.0. + + Example: + + [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9 + 192.168.1.4/30 + 192.168.1.8/29 + 192.168.1.16/28 + 192.168.1.32/27 + 192.168.1.64/26 + 192.168.1.128/25 + 192.168.2.0/23 + 192.168.4.0/22 + 192.168.8.0/22 + 192.168.12.0/29 + 192.168.12.8/31 + [root@gateway root]# + +10) A list of host/net addresses is now allowed in an entry in + /etc/shorewall/hosts. + + Example: + + foo eth1:192.168.1.0/24,192.168.2.0/24 + +11) The "shorewall check" command now includes the chain name when + printing the applicable policy for each pair of zones. + + Example: + + Policy for dmz to net is REJECT using chain all2all + + This means that the policy for connections from the dmz to the + internet is REJECT and the applicable entry in the + /etc/shorewall/policy was the all->all policy. + +12) Support for the 2.6 Kernel series has been added. diff --git a/STABLE/rules b/STABLE/rules index 5cc3c328e..b633c904b 100644 --- a/STABLE/rules +++ b/STABLE/rules @@ -107,6 +107,12 @@ # 3. You may not specify both an interface and # an address. # +# Unlike in the SOURCE column, you may specify a range of +# up to 256 IP addresses using the syntax +# -. When the ACTION is DNAT or DNAT-, +# the connections will be assigned to addresses in the +# range in a round-robin fashion. +# # The port that the server is listening on may be # included and separated from the server's IP address by # ":". If omitted, the firewall will not modifiy the @@ -137,7 +143,7 @@ # In that case, it is suggested that this field contain # "-" # -# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then +# If your kernel contains multi-port match support, then # only a single Netfilter rule will be generated if in # this list and the CLIENT PORT(S) list below: # 1. There are 15 or less ports listed. @@ -154,7 +160,7 @@ # specify an ADDRESS in the next column, then place "-" # in this column. # -# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then +# If your kernel contains multi-port match support, then # only a single Netfilter rule will be generated if in # this list and the DEST PORT(S) list above: # 1. There are 15 or less ports listed. @@ -214,6 +220,14 @@ # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # # PORT PORT(S) DEST # DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69 +# +# Example: You want to accept SSH connections to your firewall only +# from internet IP addresses 130.252.100.69 and 130.252.100.70 +# +# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL +# # PORT PORT(S) DEST +# ACCEPT net:130.252.100.69,130.252.100.70 \ +# tcp 22 ############################################################################## #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST diff --git a/STABLE/shorewall b/STABLE/shorewall index fa5555fa3..1817e16cd 100755 --- a/STABLE/shorewall +++ b/STABLE/shorewall @@ -82,6 +82,22 @@ # be automatically reinstated the # next time that Shorewall starts. # +# shorewall ipaddr [
    / |
    ] +# +# Displays information about the network +# defined by the argument[s] +# +# shorewall iprange
    -
    Decomposes a range of IP addresses into +# a list of network/host addresses. +# +# Fatal Error +# +fatal_error() # $@ = Message +{ + echo " $@" >&2 + exit 2 +} + # Display a chain if it exists # @@ -138,6 +154,13 @@ get_config() { [ -n "LOGFORMAT" ] && LOGFORMAT="${LOGFORMAT%%%*}" [ -n "$LOGFORMAT" ] || LOGFORMAT="Shorewall:" + + if [ -n "$SHOREWALL_SHELL" ]; then + if [ ! -e "$SHOREWALL_SHELL" ]; then + echo "The program specified in SHOREWALL_SHELL does not exist or is not executable" >&2 + exit 2 + fi + fi } # @@ -521,6 +544,8 @@ usage() # $1 = exit status echo " reject
    ..." echo " allow
    ..." echo " save" + echo " ipcalc [
    / |
    ]" + echo " iprange
    -
    " exit $1 } @@ -653,11 +678,13 @@ esac case "$1" in start|stop|restart|reset|clear|refresh|check) [ $# -ne 1 ] && usage 1 - exec $FIREWALL $debugging $nolock $1 + get_config + exec $SHOREWALL_SHELL $FIREWALL $debugging $nolock $1 ;; add|delete) [ $# -ne 3 ] && usage 1 - exec $FIREWALL $debugging $nolock $1 $2 $3 + get_config + exec $SHOREWALL_SHELL $FIREWALL $debugging $nolock $1 $2 $3 ;; show|list) [ $# -gt 2 ] && usage 1 @@ -860,7 +887,48 @@ case "$1" in fi mutex_off ;; + ipcalc) + if [ $# -eq 2 ]; then + address=${2%/*} + vlsm=${2#*/} + elif [ $# -eq 3 ]; then + address=$2 + vlsm=`ip_vlsm $3` + else + usage 1 + fi + + [ -z "$vlsm" ] && exit 2 + [ "x$address" = "x$vlsm" ] && usage 2 + [ $vlsm -gt 32 ] && echo "Invalid VLSM: /$vlsm" >&2 && exit 2 + + address=$address/$vlsm + + echo " CIDR=$address" + temp=`ip_netmask $address`; echo " NETMASK=`encodeaddr $temp`" + temp=`ip_network $address`; echo " NETWORK=$temp" + temp=`broadcastaddress $address`; echo " BROADCAST=$temp" + ;; + + iprange) + case $2 in + *.*.*.*-*.*.*.*) + ip_range $2 + ;; + *) + usage 1 + ;; + esac + ;; + call) + # + # Undocumented way to call functions in /usr/share/shorewall/functions directly + # + shift; + $@ + ;; *) usage 1 ;; + esac diff --git a/STABLE/shorewall.conf b/STABLE/shorewall.conf index 3bc30551e..6aa0a2f8e 100644 --- a/STABLE/shorewall.conf +++ b/STABLE/shorewall.conf @@ -144,7 +144,7 @@ BLACKLIST_LOGLEVEL= # Example: LOGNEWNOTSYN=debug -LOGNEWNOTSYN= +LOGNEWNOTSYN=info # # MAC List Log Level @@ -191,6 +191,14 @@ RFC1918_LOG_LEVEL=info # PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin +# +# SHELL +# +# The firewall script is normally interpreted by /bin/sh. If you wish to change +# the shell used to interpret that script, specify the shell here. + +SHOREWALL_SHELL=/bin/sh + # SUBSYSTEM LOCK FILE # # Set this to the name of the lock file expected by your init scripts. For @@ -230,24 +238,6 @@ MODULESDIR= # FW=fw -# -# ENABLE NAT SUPPORT -# -# You probally want yes here. Only gateways not doing NAT in any form, like -# SNAT,DNAT masquerading, port forwading etc. should say "no" here. -# -NAT_ENABLED=Yes - -# -# ENABLE MANGLE SUPPORT -# -# If you say "no" here, Shorewall will ignore the /etc/shorewall/tos file -# and will not initialize the mangle table when starting or stopping -# your firewall. You must enable mangling if you want Traffic Shaping -# (see TC_ENABLED below). -# -MANGLE_ENABLED=Yes - # # ENABLE IP FORWARDING # @@ -378,26 +368,6 @@ ROUTE_FILTER=No NAT_BEFORE_RULES=Yes -# MULTIPORT support -# -# If your kernel includes the multiport match option -# (CONFIG_IP_NF_MATCH_MULTIPORT), you may enable it's use here. When this -# option is enabled by setting it's value to "Yes" or "yes": -# -# 1) If you list more that 15 ports in a comma-seperated list in -# /etc/shorewall/rules, Shorewall will not use the multiport option -# but will generate a separate rule for each element of each port -# list. -# 2) If you include a port range (:) in the -# rule, Shorewall will not use the multiport option but will generate -# a separate rule for each element of each port list. -# -# See the /etc/shorewall/rules file for additional information on this option. -# -# if this variable is not set or is set to the empty value, "No" is assumed. - -MULTIPORT=No - # DNAT IP ADDRESS DETECTION # # Normally when Shorewall encounters the following rule: @@ -447,7 +417,7 @@ MUTEX_TIMEOUT=60 # # NEWNOTSYN # -# If this variable is set to "No" or "no", then When a TCP packet that does +# If this variable is set to "No" or "no", then when a TCP packet that does # not have the SYN flag set and the ACK and RST flags clear then unless the # packet is part of an established connection, it will be dropped by the # firewall @@ -458,6 +428,9 @@ MUTEX_TIMEOUT=60 # Users with a High-availability setup with two firewall's and one acting # as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may # also need to select NEWNOTSYN=Yes. +# +# The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis +# using the 'newnotsyn' option in /etc/shorewall/interfaces. NEWNOTSYN=No diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index 526f74ab4..4f22e88b5 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.4.5 +%define version 1.4.6 %define release 1 %define prefix /usr @@ -105,6 +105,14 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Sat Jul 19 2003 Tom Eastep +- Changed version to 1.4.6-1 +* Mon Jul 14 2003 Tom Eastep +- Changed version to 1.4.6-0RC1 +* Mon Jul 07 2003 Tom Eastep +- Changed version to 1.4.6-0Beta2 +* Fri Jul 04 2003 Tom Eastep +- Changed version to 1.4.6-0Beta1 * Tue Jun 17 2003 Tom Eastep - Changed version to 1.4.5-1 * Thu May 29 2003 Tom Eastep diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index e6738e95f..16e4cb057 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.4.5 +VERSION=1.4.6 usage() # $1 = exit status {