diff --git a/Lrp/etc/shorewall/common.def b/Lrp/etc/shorewall/common.def index ef0b4a554..5e1ce0657 100644 --- a/Lrp/etc/shorewall/common.def +++ b/Lrp/etc/shorewall/common.def @@ -16,6 +16,7 @@ run_iptables -A common -p icmp -j icmpdef ############################################################################ # NETBIOS chatter # +run_iptables -A common -p udp --dport 135 -j reject run_iptables -A common -p udp --dport 137:139 -j reject run_iptables -A common -p udp --dport 445 -j reject run_iptables -A common -p tcp --dport 139 -j reject diff --git a/Lrp/etc/shorewall/rules b/Lrp/etc/shorewall/rules index e658a9e9f..2ff32024f 100644 --- a/Lrp/etc/shorewall/rules +++ b/Lrp/etc/shorewall/rules @@ -31,6 +31,11 @@ # the companion ACCEPT rule. # REDIRECT -- Redirect the request to a local # port on the firewall. +# REDIRECT- +# -- Advanced users only. +# Like REDIRET but only generates the +# REDIRECT iptables rule and not +# the companion ACCEPT rule. # CONTINUE -- (For experts only). Do not process # any of the following rules for this # (source zone,destination zone). If diff --git a/Lrp/etc/shorewall/shorewall.conf b/Lrp/etc/shorewall/shorewall.conf index b954b59cd..8258f90ac 100644 --- a/Lrp/etc/shorewall/shorewall.conf +++ b/Lrp/etc/shorewall/shorewall.conf @@ -55,13 +55,30 @@ LOGFILE=/var/log/messages # -# LOG MARKER +# LOG FORMAT # -# Used to identify Shorewall log messages. If you are using fireparse, you must -# set this to "fp=Shorewall:". You may not use the ULOG level with fireparse and -# you must not embed white space in the LOGMARKER value. +# Shell 'printf' Formatting template for the --log-prefix value in log messages +# generated by Shorewall to identify Shorewall log messages. The supplied +# template is expected to accept either two or three arguments; the first is +# the chain name, the second (optional) is the logging rule number within that +# chain and the third is the ACTION specifying the disposition of the packet +# being logged. You must use the %d formatting type for the rule number; if your +# template does not contain %d then the rule number will not be included. +# +# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as: +# +# LOGFORMAT="fp=%s:%d a=%s " +# +# If not specified or specified as empty (LOGFORMAT="") then the value +# "Shorewall:%s:%s:" is assumed. +# +# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up +# to but not including the first '%') to find log messages in the 'show log', +# 'status' and 'hits' commands. This part should not be omitted (the +# LOGFORMAT should not begin with "%") and the leading part should be +# sufficiently unique for /sbin/shorewall to identify Shorewall messages. -LOGMARKER="Shorewall:" +LOGFORMAT="Shorewall:%s:%s:" # # LOG RATE LIMITING diff --git a/Lrp/etc/shorewall/zones b/Lrp/etc/shorewall/zones index e9b882473..4f3cdcd6f 100644 --- a/Lrp/etc/shorewall/zones +++ b/Lrp/etc/shorewall/zones @@ -3,7 +3,7 @@ # # This file determines your network zones. Columns are: # -# ZONE Short name of the zone +# ZONE Short name of the zone (5 Characters or less in length). # DISPLAY Display name of the zone # COMMENTS Comments about the zone # diff --git a/Lrp/sbin/shorewall b/Lrp/sbin/shorewall index 5a291f8b4..44c9cc5db 100755 --- a/Lrp/sbin/shorewall +++ b/Lrp/sbin/shorewall @@ -135,7 +135,9 @@ get_config() { [ -n "$FW" ] || FW=fw - [ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:" + [ -n "LOGFORMAT" ] && LOGFORMAT="${LOGFORMAT%%%*}" + + [ -n "$LOGFORMAT" ] || LOGFORMAT="Shorewall:" } # @@ -261,9 +263,9 @@ packet_log() # $1 = number of messages [ -n "$realtail" ] && options="-n$1" - grep "${LOGMARKER}\|ipt_unclean" $LOGFILE | \ + grep "${LOGFORMAT}\|ipt_unclean" $LOGFILE | \ sed s/" kernel:"// | \ - sed s/" $host $LOGMARKER"/" "/ | \ + sed s/" $host $LOGFORMAT"/" "/ | \ sed s/" $host kernel: ipt_unclean: "/" "/ | \ sed 's/MAC=.*SRC=/SRC=/' | \ tail $options @@ -734,27 +736,27 @@ case "$1" in timeout=30 - if [ `grep -c "$LOGMARKER" $LOGFILE ` -gt 0 ] ; then + if [ `grep -c "$LOGFORMAT" $LOGFILE ` -gt 0 ] ; then echo " HITS IP DATE" echo " ---- --------------- ------" - grep "$LOGMARKER" $LOGFILE | sed 's/\(.\{6\}\)\(.*SRC=\)\(.*\)\( DST=.*\)/\3 \1/' | sort | uniq -c | sort -rn + grep "$LOGFORMAT" $LOGFILE | sed 's/\(.\{6\}\)\(.*SRC=\)\(.*\)\( DST=.*\)/\3 \1/' | sort | uniq -c | sort -rn echo "" echo " HITS IP PORT" echo " ---- --------------- -----" - grep "$LOGMARKER" $LOGFILE | sed 's/\(.*SRC=\)\(.*\)\( DST=.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2 \4/ + grep "$LOGFORMAT" $LOGFILE | sed 's/\(.*SRC=\)\(.*\)\( DST=.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2 \4/ t s/\(.*SRC=\)\(.*\)\( DST=.*\)/\2/' | sort | uniq -c | sort -rn echo "" echo " HITS DATE" echo " ---- ------" - grep "$LOGMARKER" $LOGFILE | sed 's/\(.\{6\}\)\(.*\)/\1/' | sort | uniq -c | sort -rn + grep "$LOGFORMAT" $LOGFILE | sed 's/\(.\{6\}\)\(.*\)/\1/' | sort | uniq -c | sort -rn echo "" echo " HITS PORT SERVICE(S)" echo " ---- ----- ----------" - grep '${LOGMARKER}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \ + grep '${LOGFORMAT}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \ while read count port ; do # List all services defined for the given port srv=`grep "^[^#].*\\b$port/" /etc/services | cut -f 1 | sort -u` diff --git a/Lrp/usr/share/shorewall/firewall b/Lrp/usr/share/shorewall/firewall index b20fc8b84..5eae0f2a3 100755 --- a/Lrp/usr/share/shorewall/firewall +++ b/Lrp/usr/share/shorewall/firewall @@ -904,6 +904,55 @@ run_user_exit() # $1 = file name fi } +# +# Add a logging rule. +# +log_rule() # $1 = log level, $2 = chain, $3 = disposition , $... = predicates for the rule +{ + local level=$1 + local chain=$2 + local disposition=$3 + local rulenum= + + shift;shift;shift + + if [ -n "$LOGRULENUMBERS" ]; then + eval rulenum=\$${chain}_logrules + + [ -z "$rulenum" ] && rulenum=1 + + case $level in + ULOG) + eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' + ;; + *) + eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' + ;; + esac + + if [ $? -ne 0 ] ; then + [ -z "$stopping" ] && { stop_firewall; exit 2; } + fi + + rulenum=$(($rulenum + 1)) + + eval ${chain}_logrules=$rulenum + else + case $level in + ULOG) + eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' + ;; + *) + eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' + ;; + esac + + if [ $? -ne 0 ] ; then + [ -z "$stopping" ] && { stop_firewall; exit 2; } + fi + fi +} + # # Stop the Firewall # @@ -1281,18 +1330,6 @@ setup_mac_lists() { fi done < $TMP_DIR/maclist # - # Setup Logging variables - # - if [ -n "$MACLIST_LOG_LEVEL" ]; then - if [ "$MACLIST_LOG_LEVEL" = ULOG ]; then - logpart="-j ULOG $LOGPARMS --ulog-prefix" - else - logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix" - fi - else - logpart= - fi - # # Must take care of our own broadcasts and multicasts then terminate the verification # chains # @@ -1322,8 +1359,9 @@ setup_mac_lists() { shift done - [ -n "$logpart" ] && \ - run_iptables -A $chain $logpart "${LOGMARKER}$chain:$MACLIST_DISPOSITION:" + if [ -n "$MACLIST_LOG_LEVEL" ]; then + log_rule $MACLIST_LOG_LEVEL $chain $MACLIST_DISPOSITION + fi run_iptables -A $chain -j $maclist_target done @@ -1832,6 +1870,13 @@ add_nat_rule() { fi for adr in $addr; do + if [ -n "$loglevel" ]; then + ensurenatchain $chain + log_rule $loglevel $chain $logtarget -t nat \ + `fix_bang $proto $cli $sports -d $adr $multiport $dports` + loglevel= + fi + addnatrule $chain $proto $cli $sports \ -d $adr $multiport $dports -j $target1 done @@ -2017,21 +2062,11 @@ add_a_rule() if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then serv="${serv:+-d $serv}" - if [ -n "$loglevel" ]; then - if [ "$loglevel" = ULOG ]; then - run_iptables2 -A $chain $proto $multiport \ - $state $cli $sports $serv $dports -j ULOG $LOGPARMS \ - --ulog-prefix "${LOGMARKER}$chain:$logtarget:" - else - run_iptables2 -A $chain $proto $multiport \ - $state $cli $sports $serv $dports -j LOG $LOGPARMS \ - --log-prefix "${LOGMARKER}$chain:$logtarget:" \ - --log-level $loglevel - fi + log_rule $loglevel $chain $logtarget \ + `fix_bang $proto $sports $multiport $state $cli $serv $dports` fi - run_iptables2 -A $chain $proto $multiport $state $cli $sports \ $serv $dports -j $target fi @@ -2046,16 +2081,8 @@ add_a_rule() if [ $command != check ]; then if [ -n "$loglevel" ]; then - if [ "$loglevel" = ULOG ]; then - run_iptables2 -A $chain $proto $multiport \ - $dest_interface $state $cli $sports $dports -j ULOG \ - $LOGPARMS --ulog-prefix "${LOGMARKER}$chain:$logtarget:" - else - run_iptables2 -A $chain $proto $multiport \ - $dest_interface $state $cli $sports $dports -j LOG \ - $LOGPARMS --log-prefix "${LOGMARKER}$chain:$logtarget:" \ - --log-level $loglevel - fi + log_rule $loglevel $chain $logtarget \ + `fix_bang $proto $multiport $dest_interface $state $cli $sports $dports` fi if [ $logtarget != LOG ]; then @@ -2123,6 +2150,17 @@ process_rule() # $1 = target servers="$FW::$servers" fi ;; + REDIRECT-) + target=ACCEPT + logtarget=REDIRECT + dnat_only=Yes + address=${address:=all} + if [ "x-" = "x$servers" ]; then + servers=$FW + else + servers="$FW::$servers" + fi + ;; esac # Parse and validate source @@ -2263,7 +2301,7 @@ process_rules() # $1 = name of rules file while read xtarget xclients xservers xprotocol xports xcports xaddress; do case "${xtarget%:*}" in - ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|LOG|CONTINUE) + ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|REDIRECT-|LOG|CONTINUE) expandv xclients xservers xprotocol xports xcports xaddress if [ "x$xclients" = xall ]; then @@ -2556,13 +2594,7 @@ policy_rules() # $1 = chain to add rules to esac if [ $# -eq 3 -a "x${3}" != "x-" ]; then - if [ "$3" = ULOG ]; then - run_iptables -A $1 -j ULOG $LOGPARMS \ - --ulog-prefix "${LOGMARKER}${1}:${2}:" - else - run_iptables -A $1 -j LOG $LOGPARMS \ - --log-prefix "${LOGMARKER}${1}:${2}:" --log-level $3 - fi + log_rule $3 $1 $2 fi [ -n "$target" ] && run_iptables -A $1 -j $target @@ -2882,16 +2914,7 @@ setup_masq() # add_blacklist_rule() { if [ -n "$BLACKLIST_LOGLEVEL" ]; then - if [ "$BLACKLIST_LOGLEVEL" = ULOG ]; then - run_iptables2 -A blacklst $source $proto $dport -j \ - ULOG $LOGPARMS --ulog-prefix \ - "${LOGMARKER}blacklst:$BLACKLIST_DISPOSITION:" - else - run_iptables2 -A blacklst $source $proto $dport -j \ - LOG $LOGPARMS --log-prefix \ - "${LOGMARKER}blacklst:$BLACKLIST_DISPOSITION:" \ - --log-level $BLACKLIST_LOGLEVEL - fi + log_rule $BLACKLIST_LOGLEVEL blacklst $BLACKLIST_DISPOSITION `fix_bang $source $proto $dport` fi run_iptables2 -A blacklst $source $proto $dport -j $disposition @@ -3227,13 +3250,7 @@ initialize_netfilter () { createchain newnotsyn no run_user_exit newnotsyn if [ -n "$LOGNEWNOTSYN" ]; then - if [ "$LOGNEWNOTSYN" = ULOG ]; then - run_iptables -A newnotsyn -j ULOG $LOGPARMS \ - --ulog-prefix "${LOGMARKER}newnotsyn:DROP:" - else - run_iptables -A newnotsyn -j LOG $LOGPARMS \ - --log-prefix "${LOGMARKER}newnotsyn:DROP:" --log-level $LOGNEWNOTSYN - fi + log_rule $LOGNEWNOTSYN newnotsyn DROP fi run_iptables -A newnotsyn -j DROP @@ -3304,14 +3321,7 @@ build_common_chain() { # Construct zone-independent rules # add_common_rules() { - logdisp() # $1 = Chain Name - { - if [ "$RFC1918_LOG_LEVEL" = ULOG ]; then - echo "ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}${1}:DROP:" - else - echo "LOG $LOGPARMS --log-prefix ${LOGMARKER}${1}:DROP: --log-level $RFC1918_LOG_LEVEL" - fi - } + local savelogparms="$LOGPARMS" # # Reject Rules # @@ -3336,16 +3346,16 @@ add_common_rules() { createchain badpkt no if [ -n "$LOGUNCLEAN" ]; then - if [ "$LOGUNCLEAN" = ULOG ]; then - logoptions="-j ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}badpkt:DROP:" - logoptions="$logoptions --log-ip-options" - else - logoptions="-j LOG $LOGPARMS --log-prefix ${LOGMARKER}badpkt:DROP:" - logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" - fi + + LOGPARMS="$LOGPARMS --log-ip-options" - run_iptables -A badpkt -p tcp $logoptions --log-tcp-options - run_iptables -A badpkt -p ! tcp $logoptions + log_rule $LOGUNCLEAN badpkt DROP -p ! tcp + + LOGPARMS="$LOGPARMS --log-tcp-options" + + log_rule $LOGUNCLEAN badpkt DROP -p tcp + + LOGPARMS="$savelogparms" fi run_iptables -A badpkt -j DROP @@ -3368,16 +3378,15 @@ add_common_rules() { [ -z"$LOGUNCLEAN" ] && LOGUNCLEAN=info - if [ "$LOGUNCLEAN" = ULOG ]; then - logoptions="-j ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}logpkt:LOG:" - logoptions="$logoptions --log-ip-options" - else - logoptions="-j LOG $LOGPARMS --log-prefix ${LOGMARKER}logpkt:LOG:" - logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" - fi + LOGPARMS="$LOGPARMS --log-ip-options" - run_iptables -A logpkt -p tcp $logoptions --log-tcp-options - run_iptables -A logpkt -p ! tcp $logoptions + log_rule $LOGUNCLEAN logpkt DROP -p ! tcp + + LOGPARMS="$LOGPARMS --log-tcp-options" + + log_rule $LOGUNCLEAN logpkt DROP -p tcp + + LOGPARMS="$savelogparms" echo "Mangled/Invalid Packet Logging enabled on:" @@ -3414,7 +3423,9 @@ add_common_rules() { createchain rfc1918 no createchain logdrop no - run_iptables -A logdrop -j `logdisp rfc1918` + + log_rule $RFC1918_LOG_LEVEL logdrop DROP + run_iptables -A logdrop -j DROP if [ -n "$MANGLE_ENABLED" ]; then @@ -3427,7 +3438,7 @@ add_common_rules() { # run_iptables -t mangle -N man1918 run_iptables -t mangle -N logdrop - run_iptables -t mangle -A logdrop -j `logdisp man1918` + log_rule $RFC1918_LOG_LEVEL logdrop DROP -t mangle run_iptables -t mangle -A logdrop -j DROP fi @@ -3471,16 +3482,14 @@ add_common_rules() { if [ -n "$TCP_FLAGS_LOG_LEVEL" ]; then createchain logflags no - if [ "$TCP_FLAGS_LOG_LEVEL" = ULOG ]; then - run_iptables -A logflags -j ULOG $LOGPARMS \ - --ulog-prefix "${LOGMARKER}logflags:$TCP_FLAGS_DISPOSITION:" \ - --log-tcp-options --log-ip-options - else - run_iptables -A logflags -j LOG $LOGPARMS \ - --log-level $TCP_FLAGS_LOG_LEVEL \ - --log-prefix "${LOGMARKER}logflags:$TCP_FLAGS_DISPOSITION:" \ - --log-tcp-options --log-ip-options - fi + savelogparms="$LOGPARMS" + + LOGPARMS="$LOGPARMS --log-ip-options" + + log_rule $TCP_FLAGS_LOG_LEVEL logflags $TCP_FLAGS_DISPOSITION + + LOGPARMS="$savelogparms" + case $TCP_FLAGS_DISPOSITION in REJECT) run_iptables -A logflags -j REJECT --reject-with tcp-reset @@ -4344,7 +4353,8 @@ do_initialize() { SHARED_DIR=/usr/share/shorewall FUNCTIONS= VERSION_FILE= - LOGMARKER= + LOGFORMAT= + LOGRULENUMBERS= stopping= have_mutex= @@ -4470,9 +4480,27 @@ do_initialize() { else CLEAR_TC= fi + + if [ -n "$LOGFORMAT" ]; then + if [ -n "`echo $LOGFORMAT | grep '%d'`" ]; then + LOGRULENUMBERS=Yes + temp=`printf "$LOGFORMAT" fooxx 1 barxx 2> /dev/null` + if [ $? -ne 0 ]; then + startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\"" + fi + else + temp=`printf "$LOGFORMAT" fooxx barxx 2> /dev/null` + if [ $? -ne 0 ]; then + startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\"" + fi + fi - [ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:" - + if [ ${#temp} -gt 29 ]; then + startup_error "LOGFORMAT string is too long: \"$LOGFORMAT\"" + fi + else + LOGFORMAT="Shorewall:%s:%s:" + fi # # Strip the files that we use often # diff --git a/Lrp/usr/share/shorewall/version b/Lrp/usr/share/shorewall/version index 428b770e3..d0688623d 100644 --- a/Lrp/usr/share/shorewall/version +++ b/Lrp/usr/share/shorewall/version @@ -1 +1 @@ -1.4.3 +1.4.4a diff --git a/Lrp/var/lib/lrpkg/shorwall.version b/Lrp/var/lib/lrpkg/shorwall.version index 428b770e3..d0688623d 100644 --- a/Lrp/var/lib/lrpkg/shorwall.version +++ b/Lrp/var/lib/lrpkg/shorwall.version @@ -1 +1 @@ -1.4.3 +1.4.4a diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index 29425d6ba..4e3e328a4 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,13 +1,13 @@ -Changes since 1.4.2 +Changes since 1.4.3a -1. The 'add' and 'delete' commands no longer leave behind a temporary - directory in /tmp. +1. Implement REDIRECT-. -2. Added support for 6to4 tunnels. +2. Change LOGMARKER to a printf mask and allow embedded spaces. Renamed + it LOGFORMAT to avoid confusion. -3. Added $LOGMARKER for fireparse support +3. DNAT and REDIRECT logging is moved from the filter table to the nat + table. -4. Return more appropriate ICMP responses if the systems supports them. +4. Don't include log rule number when LOGFORMAT doesn't include "%d". -5. Silently drop UDP 135 in common.def. diff --git a/STABLE/documentation/6to4.htm b/STABLE/documentation/6to4.htm index eafd1d301..13c232288 100755 --- a/STABLE/documentation/6to4.htm +++ b/STABLE/documentation/6to4.htm @@ -1,141 +1,143 @@ - + 6to4 Tunnels - + - + - + - - - + + - - - + + + +
+

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 +

+ +

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

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

+ +

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.

- + +

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 - encapsulation protocol (41) will be accepted to/from the remote gateway.

- +
+ +

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

- + +

Updated 5/18/2003 - Tom Eastep +

+

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

-
+ size="2">2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.

+
+

diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index 5d9b6761e..fd1e8500f 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -1,2947 +1,3014 @@ - + - + - + Shorewall 1.4 Documentation - + - + - + - + - - - + + - - - + + + +
- +
+

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

- + - -

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

- -

It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - 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.

- -

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

- - - -

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

- - - - - - - - - - - - - - - - - - - - - - - +
  • proxyarp -- a parameter file in + /etc/shorewall used to define Proxy Arp + .
    • +
  • rfc1918 + -- a parameter file in /etc/shorewall used to define the + treatment of packets under the norfc1918 + interface option.
    • +
  • routestopped -- a parameter + file in /etc/shorewall used to define those hosts that can + access the firewall when Shorewall is stopped.
    • +
  • tcrules -- a +parameter file in /etc/shorewall used to define rules for classifying + packets for Traffic Shaping/Control.
    • +
  • tunnels -- a parameter file in +/etc/shorewall used to define IPSec tunnels.
    • +
  • shorewall -- a shell program + (requiring a Bourne shell or derivative) used to + control and monitor the firewall. This should be placed in + /sbin or in /usr/sbin (the install.sh script and the +rpm install this file in /sbin).
    • +
  • version -- a +file created in /etc/shorewall/ (/var/lib/shorewall + in version 1.3.2-1.3.8 and /usr/lib/shorewall beginning +in version 1.3.9) that describes the version of Shorewall + installed on your system.
    • - -
    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.

    - -

    Warning 1: If you rename or delete a zone, you should perform "shorewall - 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.

    - -

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

    - + + +

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

    + +

    It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally + 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.

    + +

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

    + + +

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

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

    + +

    Warning 1: If you rename or delete a zone, you should perform "shorewall + 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.

    + +

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

    + + - +

    My recommendations concerning options:
    -

    - +

    + - +

    - -

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

    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:

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

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

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

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

    /etc/shorewall/hosts - 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. - -
    - IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN DON'T TOUCH THIS -FILE!! -

    Columns in this file are:

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

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

    -
    - - - -
    -

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

    -
    - -

    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.

    - -

    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.

    - -

    Example 1:

    - -

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

    - - - -

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

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

    - -

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

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

    - - - -

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

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

    Nested and Overlapping -Zones

    - -

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

    - -

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

    - -

    /etc/shorewall/policy - Configuration.

    - -

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

    - -

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

    - -

    Four policies are defined:

    - - - -

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

    - -

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

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

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

    - -

    The policy file installed by default is as follows:

    - -
    - - - - - - - - - - - - - - - - - - + + + + + + + - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    -
    -
    ZONE INTERFACE BROADCAST OPTIONS
    netallDROPinfo
    -
    allallREJECTinfo
    -
    neteth0detectdhcp,norfc1918,blacklist
    loceth1detect
    +
    -
    - -

    This table may be interpreted as follows:

    - - - -

    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.

    - -
    +
    + +

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

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
    locallACCEPT
    -
    -
    netallDROPinfo
    -
    loclocREJECTinfo
    -
    ZONE INTERFACE BROADCAST OPTIONS
    netppp0
    +
    +
    -
    - -

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

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

    - +
    + +

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

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

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

    The CONTINUE - policy

    - -

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

    - -

    /etc/shorewall/zones:

    - -
    + IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN DON'T TOUCH +THIS FILE!! +

    Columns in this file are:

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

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

    +
    + + + +
    +

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

    +
    + +

    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.

    + +

    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.

    + +

    Example 1:

    + +

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

    + + + +

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

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

    + +

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

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

    + + + +

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

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

    Nested and Overlapping Zones

    + +

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

    + +

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

    + +

    /etc/shorewall/policy + Configuration.

    + +

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

    + +

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

    + +

    Four policies are defined:

    + + + +

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

    + +

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

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

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

    + +

    The policy file installed by default is as follows:

    + +
    + + + + - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE DISPLAY COMMENTS
    samSamSam's system at home
    netInternetThe Internet
    locLocLocal Network
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    +
    +
    netallDROPinfo
    +
    allallREJECTinfo
    +
    -
    - +
    + +

    This table may be interpreted as follows:

    + + + +

    WARNING:

    + +

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

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
    locallACCEPT
    +
    +
    netallDROPinfo
    +
    loclocREJECTinfo
    +
    +
    + +

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

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

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

    The CONTINUE + policy

    + +

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

    + +

    /etc/shorewall/zones:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE DISPLAY COMMENTS
    samSamSam's system at home
    netInternetThe Internet
    locLocLocal Network
    +
    +

    /etc/shorewall/interfaces:

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

    /etc/shorewall/hosts:

    - +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + +
    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.

    - + + +

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

    +

    /etc/shorewall/policy:

    - +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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).

    - + + +

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

    +

    Partial /etc/shorewall/rules:

    - +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ...
    -
    -
    -
    -
    -
    -
    DNATsamloc:192.168.1.3tcpssh-
    -
    DNATnetloc:192.168.1.5tcpwww-
    -
    ...
    -
    -
    -
    -
    -
    -
    -
    - -

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

    - -

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

    - -
    -

    - - - - - - - - - - - + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ...
    +
    +
    +
    +
    +
    +

    -
    -
    -
    -
    -
    -
    -
    ...
    -
    -
    -
    -
    -
    -
    DNATsamfwtcpssh-
    -
    DNATnet!samloc:192.168.1.3tcpssh-
    -
    ...
    -
    -
    -
    -
    -
    -
    DNATsamloc:192.168.1.3tcpssh-
    +
    DNATnetloc:192.168.1.5tcpwww-
    +
    ...
    +
    +
    +
    +
    +
    +
    -
    - -

    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.

    - + + +

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

    + +

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

    + +
    +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST

    +
    +
    +
    +
    +
    +
    +
    ...
    +
    +
    +
    +
    +
    +
    DNATsamfwtcpssh-
    +
    DNATnet!samloc:192.168.1.3tcpssh-
    +
    ...
    +
    +
    +
    +
    +
    +
    +
    + +

    The first rule allows Sam SSH access to the firewall. The second + rule says that any clients from the 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.

    +

    /etc/shorewall/rules

    - -

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

    - -

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

    - + +

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

    + +

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

    +

    Entries in the file have the following columns:

    - + - +

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

    - + name="PortForward"> Example 1. You wish to forward all + ssh connection requests from the internet to local +system 192.168.1.3.

    +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    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.

    - + + +

    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.

    +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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.

    - + + +

    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.

    +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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 - - .

    - + + +

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

    +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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:

    - -
    +
    + +

    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:

    + +

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

    - -

    Example 5. You wish to allow unlimited - DMZ access to the host with MAC address - 02:00:08:E3:FA:55.

    - + + +

    If you are running pure-ftpd, you would include "-p 65500:65534" on + 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.

    + +

    Example 5. You wish to allow unlimited + DMZ access to the host with MAC address + 02:00:08:E3:FA:55.

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

    Look here for information on other services. -

    - +
    + Using "DNAT-" rather than "DNAT" avoids two +extra copies of the third rule from being generated.
    + +

    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.

    - -

    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.

    - + +

    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.

    + +

    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.

    +

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

    - + +

    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 .

    +

    Columns are:

    - + - -

    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:

    - -
    + +

    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:

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

    - -
    +
    + +

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

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

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

    - -
    - - + - - - - - - - - - - - + + + + + + + + + + +
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24206.124.146.176
    INTERFACE SUBNETADDRESS
    ipsec0:10.1.0.0/16192.168.9.0/24
    +
    -
    - -

    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.

    - -
    +
    + +

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

    + +
    - - - - - - - - - - - - - + + + + + + + + + + + + +
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24206.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 + +

    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.

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

    + +

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

    - +

    The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is - typically used for enabling -Proxy ARP on a small set -of systems since -you need one -entry in this file for each - system using proxy ARP. Columns - are:

    - + href="ProxyARP.htm">Proxy ARP. The file is + typically used for +enabling Proxy ARP on a +small set of systems +since you need +one entry in this file for each + system using proxy ARP. Columns + are:

    + - -

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

    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.

    - -

    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:

    - + +

    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:

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

    - -
    + +

    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:

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

    - -

    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 +

    + +

    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.

    + +

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

    - + +

    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

    - -

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

    - + +

    + /etc/shorewall/nat

    + +

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

    +

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

    - + color="#ff0000"> 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.

    +

    Columns in an entry are:

    - + - -

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

    - -

    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.

    - + +

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

    + +

    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.

    +

    /etc/shorewall/shorewall.conf

    - +

    This file is used to set the following firewall parameters:

    - + - +

    /etc/shorewall/modules Configuration

    - -

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

    - -

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

    - + +

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

    + +

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

    +

    The loadmodule function is called as follows:

    - -
    -

    loadmodule <modulename> [ - <module parameters> ]

    -
    - + +
    +

    loadmodule <modulename> [ + <module parameters> ]

    +
    +

    where

    - -
    + +

    <modulename>

    - -
    -

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

    -
    - + +
    +

    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:

    - -
    -

    insmod moduledirectory/<modulename>.o <module - 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:

    - -
    -

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

    -
    - +
    +
    + +

    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:

    + +
    +

    insmod moduledirectory/<modulename>.o <module + 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:

    + +
    +

    insmod moduledirectory/<modulename>.o.gz <module + 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 .

    - + +

    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 .

    +

    Entries in the file have the following columns:

    - + - -
    -
    + +
    +

    Minimize-Delay (16)
    - 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.

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

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

    - +
    + +

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

    +

    /etc/shorewall/blacklist

    - -

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

    - + +

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

    + 
          130.252.100.69
          206.124.146.0/24
    - -

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

    - + +

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

    +

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

    - +

    + - -

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

    - + +

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

    - + +

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

    - -
    + +

    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.

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

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

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

    Updated 5/18/2003 - Tom Eastep -

    - +
    + +

    Updated 5/27/2003 - Tom Eastep +

    +

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

    diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index a23d7a211..a2fb782f3 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -1,1296 +1,1303 @@ - + - + - + - + Shorewall FAQ - + - + - - - + + - - - + + + +
    +

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

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

    - +
    +
    +
    + +
    +

    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.
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATnetloc:<local - IP address>[:<local port>]<protocol><port - #>
    -
    -
    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.
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATnetloc:192.168.1.5udp7777
    -
    -
    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.
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATnetloc:<local - IP address>[:<local port>]<protocol><port - #>-<external - IP>
    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:

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

    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.

    - -

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

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

    - -

    Otherwise:
    -

    - +

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

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

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

    and make your DNAT rule:

    -
    - -
    -
    + +

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

    + +

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

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

    + +

    Otherwise:
    +

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

    - -
    -

    Using this technique, you will want to configure your DHCP/PPPoE - client to automatically restart Shorewall each + +

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

    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:

    - +
    + +

    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 + b) Masquerade Z to itself.
    -
    - Example:

    - +
    + Example:

    +

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

    - + Interface: eth2
    + Subnet: 192.168.2.0/24

    +

    In /etc/shorewall/interfaces:

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

    In /etc/shorewall/policy:

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

    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?

    + +

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

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

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

    + +

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

    + +
    +

    http://www.shorewall.net/pub/shorewall/parsefw/
    + http://www.fireparse.com
    + http://cert.uni-stuttgart.de/projects/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:
    + +
    	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?

    + +
    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:
    + +
      +
    1. They are late-arriving replies to DNS queries.
      2. +
    2. They are corrupted reply packets.
      3. + +
    + 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 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
    + +
      +
    • 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:

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

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

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

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

    + +

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

    + +

    11. What Features does it have?

    + +

    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 +

    + +

    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:

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

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

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

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

    + +

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

    + +
    + + + + + - - - - - -
    SUBNET
    +     		TARGET
    +
    eth2192.168.2.0/24
    -
    -
    - -

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

    - -
    -
         LOGLIMIT=""
         LOGBURST=""
    - Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages - to a separate file.
    -
    - -

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

    - -

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

    - -
    -

    http://www.shorewall.net/pub/shorewall/parsefw/
    - http://www.fireparse.com
    - http://cert.uni-stuttgart.de/projects/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:
    - -
    	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?

    - -
    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:
    - -
      -
    1. They are late-arriving replies to DNS queries.
      2. -
    2. They are corrupted reply packets.
      3. - -
    - 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 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
    - -
      -
    • 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:

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

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

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

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

    - -

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

    - -

    11. What Features does it have?

    - -

    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 -

    - -

    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:

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

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

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

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

    - -

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

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

    4. + +

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

      +
      5. +
    5. + +

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

      +
      6. +
    6. + +

      The DNS settings on the local systems are wrong or the + user is running a DNS server on the firewall + and hasn't enabled UDP and TCP port 53 from the firewall to the internet.

      -
      7. - + +
    - -

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

    - -

    Answer: "man dmesg" -- add a suitable 'dmesg' command - to your startup scripts or place it in /etc/shorewall/start. - Under RedHat, the max log level that is sent to - the console is specified in /etc/sysconfig/init in the - LOGLEVEL variable.
    -

    - -

    17. How do I find out why this 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: "man dmesg" -- add a suitable 'dmesg' command + to your startup scripts or place it in /etc/shorewall/start. + Under RedHat, the max log level that is sent +to the console is specified in /etc/sysconfig/init in +the LOGLEVEL variable.
    +

    + +

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

    + Answer: Logging + occurs out of a number of chains (as indicated in the + log message) in Shorewall:
    +
      -
    1. man1918 - The - destination address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see man1918 - The + destination address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
      2. -
    2. rfc1918 -- The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see rfc1918 +- The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
      3. -
    3. all2<zone>, - <zone>2all or all2all - - You have a policy that specifies - a log level and this packet is being logged under that policy. - If you intend to ACCEPT this traffic then you need a rule to that effect.
      -
      4. -
    4. <zone1>2<zone2> - - Either you have a policy for <zone1> - to <zone2> that specifies a log level and - this packet is being logged under that policy or this packet - matches a rule that includes - a log level.
      5. -
    5. <interface>_mac - - The packet is being logged under the maclist - interface option.
      -
      6. -
    6. logpkt - -The packet is being logged under the logunclean - interface option.
      7. -
    7. badpkt - -The packet is being logged under the dropunclean - interface option -as specified in the LOGUNCLEAN setting in all2<zone>, + <zone>2all or all2all + - You have a policy +that specifies a log level and this packet is being +logged under that policy. If you intend to ACCEPT this +traffic then you need a rule to +that effect.
      +
      8. +
    8. <zone1>2<zone2> + - Either you have a policy for <zone1> + to <zone2> that specifies a log level and + this packet is being logged under that policy or this packet + matches a rule that +includes a log level.
      9. +
    9. <interface>_mac + - The packet is being logged under the maclist + interface option.
      +
      10. +
    10. logpkt +- The packet is being logged under the logunclean + interface option.
      11. +
    11. badpkt - + The packet is being logged under the dropunclean + interface option + as specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
      12. -
    12. blacklst -- The packet is being logged because the source IP -is blacklisted in the /etc/shorewall/blacklist - file.
      13. -
    13. newnotsyn - - The packet is being logged because it is a TCP packet - that is not part of any current connection yet it is not a -syn packet. Options affecting the logging of such packets include - NEWNOTSYN and LOGNEWNOTSYN in +
    14. blacklst + - The packet is being logged because the source IP + is blacklisted in the /etc/shorewall/blacklist + file.
      15. +
    15. newnotsyn - + The packet is being logged because it is a TCP packet + that is not part of any current connection yet it is not a +syn packet. Options affecting the logging of such packets include + NEWNOTSYN and LOGNEWNOTSYN in /etc/shorewall/shorewall.conf.
      16. -
    16. INPUT or - FORWARD - The packet has a source IP address - that isn't in any of your defined zones ("shorewall check" - and look at the printed zone definitions) or the chain is FORWARD +
    17. 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.
      18. -
    18. logflags - The packet - is being logged because it failed the checks implemented +
    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
    +
    + 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.

    - 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.
    - + 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
    -
    - Last updated 4/14/2003 - Tom Eastep + +

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

    + At the shell prompt, type:
    +
    + /sbin/shorewall version
    +
    + Last updated 4/14/2003 - Tom Eastep

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

    +

    +



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

    Shorewall Installation and - Upgrade

    -
    +

    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.

    + - -

    To install Shorewall using the tarball - and install script:

    - - - -

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

    - + +

    To install Shorewall using the tarball + and install script:

    + - 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 - QuickStart Guides contain all of the information you need.

    - + +

    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.

    + - -

    Updated 4/8/2003 - Tom Eastep -

    - + +

    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 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 + QuickStart Guides contain all of the information you need.

    + + + +

    Updated 4/8/2003 - Tom Eastep +

    +

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

    +

    +
    diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 43bd19380..c5b0ac99b 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -4,7 +4,7 @@ - + Shorewall News @@ -13,200 +13,255 @@ - + + - + - + - - - + + - + + - - + + +
    +
    - +

    Shorewall News Archive

    -
    - + +

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

    + 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. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) - by setting LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. Note: You may - not use ULOG with fireparse unless you modify fireparse.
      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. (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
      5. +
    5. 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.
      6. + +
    + +

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

    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

    - + @@ -225,2916 +280,2964 @@ affected all (zone,interface,address) tuples associated with the given - -

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

    - + +

    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. - +
    2. 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.
      3. +
    - 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:
    - + 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.
    -
    - + 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. - +
    4. 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.
      5. +
    5. Beginning with Shorewall 1.4.1, Shorewall will never create + rules to handle traffic from a group to itself.
      6. +
    6. A NONE policy is introduced in 1.4.1. When a policy of +NONE is specified from Z1 to Z2:
      7. +
    - + - See the upgrade issues for a discussion - of how these changes may affect your configuration. + 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:
    - + 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:

    - - - - - -

    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. -
    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. 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.
      +
      +
      5. +
    5. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
      +
      +
      6. +
    6. 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.
      +
      +
      7. +
    7. 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.
      +
      +
      8. +
    8. The Shorewall 1.2 syntax for DNAT and REDIRECT +rules is no longer accepted.
      +
      +
      9. +
    9. The ALLOWRELATED variable in shorewall.conf is +no longer supported. Shorewall 1.4 behavior is the same as 1.3 with + ALLOWRELATED=Yes.

      10. -
    10. Support for VLAN devices with names of the form -$DEV.$VID (e.g., eth0.0)
      -
      -
      11. -
    11. 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.
      -
      +
    12. The icmp.def file has been removed.
      13. -
    13. 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
      -
      14. - -
    - -


    - 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

    + + Changes for 1.4 include:
    -

    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
    -

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

    + + + + + +

    2/8/2003 - Shoreawall 1.3.14

    -

    The Beta includes the following changes:
    -

    +

    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.
      +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. 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. 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.
      -   
      + 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:
      -   
      +  
      + 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?
      -  
      +  
      +    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
      -
      8. +
    +


    + 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

    + +

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

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

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

    - + href="http://www.rettc.com">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. - +
    5. 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,....
      +
      +
      6. +
    6. The 'shorewall check' command now +prints out the applicable policy between each pair of zones.
      +
      +
      7. +
    7. 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.
      +
      +
      8. +
    8. 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.
      +
      9. +
    - -

    1/6/2003 - BURNOUT -

    - -

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

    - + +

    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 to a separate log file.
      6. -
    6. If you are running a kernel that has - a FORWARD chain in the mangle table ("shorewall show mangle" - will show you the chains in the mangle table), you can set -MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. -This allows for marking input packets based on their destination -even when you are using Masquerading or SNAT.
      7. -
    7. I have cluttered up the /etc/shorewall - directory with empty 'init', 'start', 'stop' and 'stopped' - files. If you already have a file with one of these names, don't - worry -- the upgrade process won't overwrite your file.
      8. -
    8. I have added a new RFC1918_LOG_LEVEL - variable to shorewall.conf. - This variable specifies the syslog level at which packets -are logged as a result of entries in the /etc/shorewall/rfc1918 -file. Previously, these packets were always logged at the 'info' -level.
      -
      9. - -
    - -

    12/20/2002 - Shorewall 1.3.12 Beta 3
    -

    - This version corrects a problem with Blacklist - logging. In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything - but ULOG, the firewall would fail to start and "shorewall refresh" - would also fail.
    - -

    12/20/2002 - Shorewall 1.3.12 Beta 2

    - -

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

    - Features include:
    +

    1. "shorewall refresh" now reloads - the traffic shaping rules (tcrules and tcstart).
      2. + the traffic shaping rules (tcrules and tcstart).
    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. + turns off debugging after an error occurs. This places +the point of the failure near the end of the trace rather +than up in the middle of it.
    3. "shorewall [re]start" has been -speeded up by more than 40% with my configuration. Your milage -may vary.
      4. +speeded up by more than 40% with my configuration. Your milage +may vary.
    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. +command has been added which shows the current packet classification + filters. The output from this command is also added as +a separate page in "shorewall monitor"
    5. ULOG (must be all caps) is now -accepted as a valid syslog level and causes the subject packets -to be logged using the ULOG target rather than the LOG target. - This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) - and log all Shorewall messages http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
    6. If you are running a kernel that - has a FORWARD chain in the mangle table ("shorewall show -mangle" will show you the chains in the mangle table), you can -set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for - marking input packets based on their destination even when you -are using Masquerading or SNAT.
      7. + has a FORWARD chain in the mangle table ("shorewall show + mangle" will show you the chains in the mangle table), you + can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for +marking input packets based on their destination even when you + are using Masquerading or SNAT.
    7. I have cluttered up the /etc/shorewall - directory with empty 'init', 'start', 'stop' and 'stopped' - files. If you already have a file with one of these names, don't - worry -- the upgrade process won't overwrite your file.
      8. + directory with empty 'init', 'start', 'stop' and 'stopped' + files. If you already have a file with one of these names, +don't worry -- the upgrade process won't overwrite your file. +
    8. I have added a new RFC1918_LOG_LEVEL + variable to shorewall.conf. + This variable specifies the syslog level at which packets + are logged as a result of entries in the /etc/shorewall/rfc1918 + file. Previously, these packets were always logged at the 'info' + level.
      +
    - You may download the Beta from:
    +

    12/20/2002 - Shorewall 1.3.12 Beta 3
    +

    + This version corrects a problem with + Blacklist logging. In Beta 2, if BLACKLIST_LOG_LEVEL was +set to anything but ULOG, the firewall would fail to start and +"shorewall refresh" would also fail.
    + + +

    12/20/2002 - Shorewall 1.3.12 Beta 2

    + + +

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

    + Features include:
    + + +
      +
    1. "shorewall refresh" now reloads + the traffic shaping rules (tcrules and tcstart).
      2. +
    2. "shorewall debug [re]start" + now turns off debugging after an error occurs. This places + the point of the failure near the end of the trace rather than + up in the middle of it.
      3. +
    3. "shorewall [re]start" has +been speeded up by more than 40% with my configuration. Your +milage may vary.
      4. +
    4. A "shorewall show classifiers" + command has been added which shows the current packet +classification filters. The output from this command is also +added as a separate page in "shorewall monitor"
      5. +
    5. ULOG (must be all caps) is + now accepted as a valid syslog level and causes the subject + packets to be logged using the ULOG target rather than the +LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
      6. +
    6. If you are running a kernel + that has a FORWARD chain in the mangle table ("shorewall + show mangle" will show you the chains in the mangle table), + you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This + allows for marking input packets based on their destination even + when you are using Masquerading or SNAT.
      7. +
    7. I have cluttered up the /etc/shorewall + directory with empty 'init', 'start', 'stop' and 'stopped' + files. If you already have a file with one of these names, + don't worry -- the upgrade process won't overwrite your file.
      8. + + +
    + You may download the Beta from:
    + +
    http://www.shorewall.net/pub/shorewall/Beta
    - ftp://ftp.shorewall.net/pub/shorewall/Beta
    -
    - + + +

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

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

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

    + +

    Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. + I have installed 9.0 on one of my systems and I am +now in a position to support Shorewall users who run Mandrake + 9.0.

    - +

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

    +

    - +

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

    - +

    12/3/2002 - Shorewall 1.3.11a

    - -

    This is a bug-fix roll up which includes Roger Aich's fix for DNAT with - excluded subnets (e.g., "DNAT foo!bar ..."). Current -1.3.11 users who don't need rules of this type need not upgrade -to 1.3.11.

    + +

    This is a bug-fix roll up which includes Roger Aich's fix for DNAT with + excluded subnets (e.g., "DNAT foo!bar ..."). Current + 1.3.11 users who don't need rules of this type need not + upgrade to 1.3.11.

    - +

    11/24/2002 - Shorewall 1.3.11

    - +

    In this version:

    - - - - -

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

    - - - -

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

    11/14/2002 - Shorewall Documentation in PDF Format

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

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

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

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

      - -
    - Hopefully these -problems are now corrected.
    + +

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

    - -

    9/18/2002 -  Debian 1.3.8 Packages Available
    -

    + +

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

    - + +

    11/09/2002 - Shorewall 1.3.10

    + + +

    In this version:

    + + + + + +

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

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

    10/23/2002 - Shorewall 1.3.10 Beta 1

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

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

    + +

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

    - + +

    10/9/2002 - Shorewall 1.3.9b

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

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

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

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

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

    9/28/2002 - Shorewall 1.3.9

    + + +

    In this version:
    +

    + + + + + +

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

    +

    - + - + - +

    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:

    - + - -

    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:

    - + - +

    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:

    - + - +

    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:

    - + - +

    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:

    - + - -

    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 The 1.3.0 samples configurations had several serious problems that prevented + DNS and SSH from working properly. These + problems have been corrected in the 1.3.1 samples.

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    5/29/2002 - Shorewall 1.3.0 Released

    - -

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

    + +

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

    - + - +

    5/23/2002 - Shorewall 1.3 RC1 Available

    - -

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

    + +

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

    - + - +

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    - -

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

    + +

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

    - + - +

    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:

    - + - +

    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

    - + - +

    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:

    - + - +

    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:

    - + - +

    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:

    - + - +

    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:

    - + - +

    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:

    - + - +

    1/28/2002 - Shorewall 1.2.4 Released

    - + - +

    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:

    - + - +

    The following problems were corrected:

    - + - +

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

    - + - +

    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:

    + target="_blank">version 1.2.0) released. These are minor updates + to the previously-released samples. There + are two new rules added:

    - + - +

    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 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 those of you who have installed one of the Beta RPMS, you will need + to use the "--oldpackage" option when upgrading + to 1.2.0:

    - -
    + +
    - +

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

    -
    +
    - -

    12/19/2001 - Thanks to Steve - Cowles, there is now a Shorewall mirror - in Texas. This web site is mirrored at http://www.infohiiway.com/shorewall - and the ftp site is at 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:

    - + - +

    11/20/2001 - The current version of Shorewall is 1.1.18. 

    - +

    In this version:

    - + - -

    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:

    - + - +

    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:

    - + - -

    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:

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - -

    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

    - + - +

    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:

    - + - +

    3/25/2001 - The current version of Shorewall is 1.1.0. In this version:

    - + - +

    3/19/2001 - The current version of Shorewall is 1.0.4. This version:

    - + - -

    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.

    - + - -

    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.

    + +

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

    + +

    Updated 5/27/2003 - Tom Eastep +

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    +

    +

    diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index dcabb59d5..e3046f3fe 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -1,274 +1,298 @@ - + Shorewall 1.4 Errata - + - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Shorewall Errata/Upgrade Issues

    -
    - +

    IMPORTANT

    - +
      -
    1. +

    2. If you use a Windows system to download - a corrected script, be sure to run the script through - + dos2unix after you have moved - it to your Linux system.

      -
      3. -
    3. + it to your Linux system.

      +
      4. +

    4. If you are installing Shorewall for the first time and plan to use the .tgz and install.sh script, you can untar the archive, replace the 'firewall' script in the untarred directory - with the one you downloaded below, and then run install.sh.

      -
      5. -
    5. + with the one you downloaded below, and then run install.sh.

      +
      6. +

    6. When the instructions say to install a corrected - firewall script in /usr/share/shorewall/firewall, you + firewall script in /usr/share/shorewall/firewall, you may rename the existing file before copying in the new file.

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

    - +

    - -

    1.4.2

    + +

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

    1.4.3

      -
    • 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 ablve.
      +
    • The LOGMARKER variable introduced in version 1.4.3 was intended to +allow integration of Shorewall with Fireparse (http://www.firewparse.com). +Unfortunately, LOGMARKER only solved part of the integration problem. I have +implimented a new LOGFORMAT variable which will replace LOGMARKER which has +completely solved this problem and is currently in production with fireparse +here at shorewall.net. The updated files may be found at ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/. +See the 0README.txt file for details.
    -

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

    1.4.1

    +

    1.4.2

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

    1.4.0

    +

    1.4.1a, 1.4.1 and 1.4.0

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

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

    1.4.0

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

    - -
    + iptables version 1.2.3 + +

    There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, -RedHat released this buggy iptables in RedHat 7.2. 

    - + prevent it from working with Shorewall. Regrettably, + RedHat released this buggy iptables in RedHat 7.2. 

    +

    I have built a - corrected 1.2.3 rpm which you can download here  and I + 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.

    - + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

    +

    Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can - download from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works - fine.

    - + I have installed this RPM on my firewall and it +works fine.

    +

    If you would like to patch iptables 1.2.3 yourself, - the patches are available for download. This patch - which corrects a problem with parsing of the --log-level -specification while this patch - corrects a problem in handling the  TOS target.

    - + corrects a problem in handling the  TOS target.

    +

    To install one of the above patches:

    - +
      -
    • cd iptables-1.2.3/extensions
      • -
    • patch -p0 < the-patch-file
      • - +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • +
    -
    - +
    +

    Problems with kernels >= 2.4.18 and RedHat iptables

    - -
    + +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 - may experience the following:

    - -
    + may experience the following:

    + + 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    -
    - +
    +

    The RedHat iptables RPM is compiled with debugging enabled but the user-space debugging code was not updated to reflect recent changes in the Netfilter 'mangle' table. You can correct the problem by - installing - this iptables RPM. If you are already running a 1.2.5 -version of iptables, you will need to specify the --oldpackage -option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    -
    - + this iptables RPM. If you are already running a 1.2.5 + version of iptables, you will need to specify the --oldpackage + option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    +
    +

    Problems installing/upgrading - RPM on SuSE

    - + RPM on SuSE +

    If you find that rpm complains about a conflict with kernel <= - 2.2 yet you have a 2.4 kernel installed, simply use the "--nodeps" - option to rpm.

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

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

    - + change to the syntax used to specify multiport match rules; as + a consequence, if you install iptables 1.2.7 you must +be running Shorewall 1.3.7a or later or:

    + - +

    Problems with RH Kernel 2.4.18-10 and NAT
    -

    - /etc/shorewall/nat entries of the following form will - result in Shorewall being unable to start:
    -
    - + + /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
    - -

    Last updated 5/11/2003 - Tom Eastep + 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 5/27/2003 - Tom Eastep

    - +

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

    -
    +

    diff --git a/STABLE/documentation/images/Legend.png b/STABLE/documentation/images/Legend.png new file mode 100755 index 000000000..8ae90a1ec Binary files /dev/null and b/STABLE/documentation/images/Legend.png differ diff --git a/STABLE/documentation/seattlefirewall_index.htm b/STABLE/documentation/seattlefirewall_index.htm index 22580a69b..bc913d13d 100644 --- a/STABLE/documentation/seattlefirewall_index.htm +++ b/STABLE/documentation/seattlefirewall_index.htm @@ -2,107 +2,117 @@ - + Shoreline Firewall (Shorewall) 1.4 - + - + - - - - + + + - + + - - + +
    +
    + + +

    Shorwall Logo - (Shorewall Logo) -

    - + (Shorewall Logo) + + + - -
    + +
    - +

    Shorewall 1.4 "iptables made easy"
    -
    +
    -

    -
    + +
    - +

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

    What is it?

    - -

    The Shoreline Firewall, more commonly known as "Shorewall", is -a Netfilter (iptables) based -firewall that can be used on a dedicated firewall system, a multi-function - gateway/router/server or on a standalone GNU/Linux system.

    + + +

    The Shoreline Firewall, more commonly known as "Shorewall", is a + Netfilter (iptables) based firewall + that can be used on a dedicated firewall system, a multi-function + gateway/router/server or on a standalone GNU/Linux system.

    - -

    This program is free software; you can redistribute it and/or modify - it - under the terms of Version 2 of the -GNU General Public License as published by the Free Software - Foundation.
    -
    - This - program is distributed in the hope that - it will be useful, but WITHOUT ANY WARRANTY; - without even the implied warranty of MERCHANTABILITY - or FITNESS FOR A PARTICULAR PURPOSE. - See the GNU General Public License for more details.
    + +

    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.
    -
    - You - should have received a copy of the GNU - General Public License along with - this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, - MA 02139, USA

    +
    + + This program is distributed in the hope + that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty + of MERCHANTABILITY or FITNESS FOR A PARTICULAR + PURPOSE. See the GNU General Public License + for more details.
    + +
    + + You should have received a copy of the + GNU General Public License along + with this program; if not, write to the Free + Software Foundation, Inc., 675 Mass + Ave, Cambridge, MA 02139, USA

    - + +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -110,216 +120,288 @@ GNU General Public License as published by the Free Software - -

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

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

    News

    - -

    5/20/2003 - Shorewall-1.4.3a 5/27/2003 - Shorewall-1.4.4a (New) -
    -

    -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

    + 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 (New) -
    -

    -     Problems Corrected:
    +

    + 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. 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. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) - by setting LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. -Note: You may not use ULOG with fireparse unless you modify fireparse.
      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

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

    The list server will be down this morning for upgrade to RH9.0.
    -

    + + +

    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  

    -

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

    +

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

    - -

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

    + +

    4/26/2003 - lists.shorewall.net Downtime

    - -

    4/12/2002 - Greater Seattle Linux Users Group Presentation -

    + +

    The list server will be down this morning for upgrade to RH9.0.
    +

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

    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/12/2002 - Greater Seattle Linux Users Group Presentation +

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

    +

    - 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.
    - + action="http://lists.shorewall.net/cgi-bin/htsearch"> +
    + Note: +     Search is unavailable + Daily 0200-0330 GMT.
    + - +

    Quick Search
    -

    - +

    +
    - - + +

    Extended Search

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

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

    + +

    Updated 5/27/2003 - Tom Eastep +
    +

    +
    +
    diff --git a/STABLE/documentation/shorewall_firewall_structure.htm b/STABLE/documentation/shorewall_firewall_structure.htm index cf8c57a81..b27c3ee0b 100644 --- a/STABLE/documentation/shorewall_firewall_structure.htm +++ b/STABLE/documentation/shorewall_firewall_structure.htm @@ -1,175 +1,334 @@ + - - - - - -Shorewall Firewall Structure + + + + + + + + + Shorewall Firewall Structure - - - - - - - -
    -

    Firewall Structure

    -
    -

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

    -
      -
    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 since their servers -may have been compromised through a security exploit.
      3. -
    3. - 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.
      4. -
    -

    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.

    -

    While zones are normally disjoint (no two zones have a host in common), - there are cases where nested or overlapping zone definitions are appropriate.

    -

    For a general picture of how packets traverse a Netfilter firewall, see - - http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES.
    + + + + + + + + + +
    +

    Firewall Structure

    +
    + +

    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:

    + +
      +
    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 +since their servers may have been compromised through a security exploit.
      3. +
    3. 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.
      4. + +
    + +

    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.

    + +

    While zones are normally disjoint (no two zones have a host in common), + 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. + +
    + +

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

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

    + +
    (Box Legend)
    - 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  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 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 address doesn't match any of the rules in the - interface_in chain then the packet enters a chain called sourcezone_dnat +

    + +

    + +

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

    + +
    Netfilter Flow Diagram +
    + +


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

      -

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

      -

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

      -

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

      -

      - For each record in the /etc/shorewall/policy file, a chain is created. Policies -in that file are expressed in terms of a source zone and destination zone -where these zones may be a zone defined in /etc/shorewall/zones, "fw" or -"all". Policies specifying the pseudo-zone "all" matches all defined zones -and "fw". These chains are referred to as 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. -
      -

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

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

      - Just because connections of a particular type are allowed between zone A - and the firewall and are also allowed between the firewall and zone B - 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.

      -

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

      -

      Last modified 8/22/2002 - Tom -Eastep

      -Copyright © 2001, 2002 Thomas M. Eastep. \ No newline at end of file + 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.
      +
      +

      2. +
    2. 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.
      3. + +
        +
      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. + +
      +
    3. 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.
      4. + +
    + +

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

    + +

    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.

    + +

    For each record in the /etc/shorewall/policy file, a chain is created. + Policies in that file are expressed in terms of a source zone and destination + zone where these zones may be a zone defined in /etc/shorewall/zones, +"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined + zones and "fw". These chains are referred to as 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. + +
    + +

    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:

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

    Just because connections of a particular type are allowed between zone + A and the firewall and are also allowed between the firewall and zone +B 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.

    + +

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

    + +

    Last modified 5/22/2003 - Tom Eastep

    + +

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

    +
    +
    +
    + + diff --git a/STABLE/documentation/sourceforge_index.htm b/STABLE/documentation/sourceforge_index.htm index 5f6fd28dd..27258896c 100644 --- a/STABLE/documentation/sourceforge_index.htm +++ b/STABLE/documentation/sourceforge_index.htm @@ -2,335 +2,420 @@ - + Shoreline Firewall (Shorewall) 1.3 - + - + - - + - + + - + + + - - + +
    +
    +

    Shorwall Logo - Shorewall 1.4 - - "iptables made easy"
    - Shorewall 1.4 + - "iptables made +easy"
    +
    -     + -

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

    What is it?

    - -

    The Shoreline Firewall, more commonly known as "Shorewall", is - a Netfilter - (iptables) based firewall that can be used on - a dedicated firewall system, a multi-function gateway/router/server - or on a standalone GNU/Linux system.

    - - -

    This program is free software; you can redistribute it and/or modify - it - under the terms of Version 2 of the -GNU General Public License as published by the Free Software - Foundation.
    - -
    - -This program is distributed in the hope - that it will be useful, but WITHOUT ANY - WARRANTY; without even the implied warranty - of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License - for more details.
    - -
    - -You should have received a copy of the GNU - General Public License along with - this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, - MA 02139, USA

    - - - -

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    + +

    The Shoreline Firewall, more commonly known as "Shorewall", is + a Netfilter + (iptables) based firewall that can be used +on a dedicated firewall system, a multi-function + gateway/router/server or on a standalone GNU/Linux system.

    +

    This program is free software; you can redistribute it and/or modify + it + under the terms of Version 2 of the GNU +General Public License as published by the Free Software + Foundation.
    + +
    + + This program is distributed in the hope + that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty + of MERCHANTABILITY or FITNESS FOR A PARTICULAR + PURPOSE. See the GNU General Public License + for more details.
    + +
    + + You should have received a copy of the + GNU General Public License along + with this program; if not, write to the Free + Software Foundation, Inc., 675 Mass + Ave, Cambridge, MA 02139, USA

    + + + + +

    Copyright 2001, 2002, 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.
    - + 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.
    - + New to Shorewall? Start by selecting the QuickStart Guide that most closely + match your environment and follow the step by step instructions.
    + +

    News

    - + - -

    5/20/2003 - Shorewall-1.4.3a 5/27/2003 - Shorewall-1.4.4a (New) -
    -

    -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

    + 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 (New) -
    -

    -     Problems Corrected:
    -     +

    + 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. 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. - +
    3. 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.
      +
      +
      4. +
    4. 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.
      +
      +
      5. +
    5. 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.
      6. +
    -     New Features:
    -     + +

    5/20/2003 - Shorewall-1.4.3a +
    +

    + This version primarily corrects the documentation included in the .tgz + and in the .rpm. In addition:
    +
      -
    1.  IPV6-IPV4 (6to4) -tunnels are now supported in the /etc/shorewall/tunnels file.
      2. -
    2. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) by setting -LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. -Note: You may not use ULOG with fireparse unless you modify fireparse.
      3. - +
    3. (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
      4. +
    4. 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.
      +
      5. +
    - -

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

    + +

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

      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 -

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

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

    + +

    5/8/2003 - Shorewall Mirror in Chile  

    + + +

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

    -

    4/12/2002 - Greater Seattle Linux Users Group Presentation -

    +

    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 +

    + + +

    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 +

    + + +
    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.
    + target="_top">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.3.14 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

    -     		- + +
    - + action="http://lists.shorewall.net/cgi-bin/htsearch"> + +


    - Note:     - Search is unavailable Daily 0200-0330 - GMT.
    -  

    - - + Note: + Search is unavailable Daily 0200-0330 + GMT.
    +  

    + +

    Quick Search
    - - +

    - -
    - + + + +

    Extended Search

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

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

    + +

    Updated 5/27/2003 - Tom Eastep +
    +

    +
    +
    +
    diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index a646d340e..368f20fa9 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -1,79 +1,81 @@ - + - + Shorewall Support Guide - + - - - + + - - - + + + + +
    - +
    +

    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: - + action="http://lists.shorewall.net/cgi-bin/htsearch"> Match: + - Format: + Format: + - Sort by: + Sort by: + - Include Mailing List Archives: - + size="-1"> Include Mailing List Archives: + -
    - Search:
    + Search:
    - -
    - + +
    +

    Problem Reporting Guidelines
    -

    - + + - + - + - -
    The author gratefully acknowleges that the above list was - heavily plagiarized from the excellent LEAF document by Ray + +
    The author gratefully acknowleges that the above list was + heavily plagiarized from the excellent LEAF document by 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 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.
    - + +

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

    Where to Send your Problem Report or to Ask for Help

    - -
    If you have a quick question about -capabilities or where to find something, you may use the Shorewall Support - Forum. DO NOT POST THE OUTPUT OF "shorewall status" TO THE FORUM; - I WON'T LOOK AT IT. If you need to supply "shorewall status" -output, use the appropriate mailing list below.
    - + +

    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 Shorewall users mailing - list. Do not expect to get free MNF support on the list.
    - + style="font-weight: 400;">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 Shorewall users mailing + list. Do not expect to get free MNF support on the list.
    +

    Otherwise, please post your question or problem to the Shorewall users mailing - list .

    - + href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing + list .

    +

    To Subscribe to the mailing list go to http://lists.shorewall.net/mailman/listinfo/shorewall-users - .
    -

    -
    - + href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users + .
    +

    +
    +

    For information on other Shorewall mailing lists, go to http://lists.shorewall.net
    -

    - -

    Last Updated 5/12/2003 - Tom Eastep

    - +

    + +

    Last Updated 5/19/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 f5a621fb7..dd86feb72 100644 --- a/STABLE/documentation/three-interface.htm +++ b/STABLE/documentation/three-interface.htm @@ -1,1212 +1,1198 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    +

    Three-Interface Firewall

    -
    - +

    Version 2.0.1

    - -

    Setting up a Linux system as a firewall for a small network - with DMZ is a fairly straight-forward task if you understand the + +

    Setting up a Linux system as a firewall for a small network + with DMZ is a fairly straight-forward task if you understand the basics and follow the documentation.

    - -

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall + +

    This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall in one of its more popular configurations:

    - +
      -
    • Linux system used as a firewall/router for a small -local network.
      • -
    • Single public IP address.
      • -
    • DMZ connected to a separate ethernet interface.
      • -
    • Connection through DSL, Cable Modem, ISDN, Frame Relay, - dial-up, ...
      • - +
    • Linux system used as a firewall/router for a small + local network.
      • +
    • Single public IP address.
      • +
    • DMZ connected to a separate ethernet interface.
      • +
    • Connection through DSL, Cable Modem, ISDN, Frame +Relay, dial-up, ...
      • +
    - +

    Here is a schematic of a typical installation.

    - +

    -

    - -

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

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

    - +

    +

    -     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 +     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 +     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 + href="http://www.shorewall.net/pub/shorewall/Samples/">three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy + the files to /etc/shorewall (the files will replace files with the same names that were placed in /etc/shorewall when Shorewall was installed).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration + +

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

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the three-interface sample configuration, + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the three-interface sample configuration, the following zone names are used:

    - + - + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    NameDescription
    NameDescription
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    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, + +

    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.

    - +
      -
    • You express your default policy for connections from +
    • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
      • -
    • You define exceptions to those default policies in -the /etc/shorewall/rules file.
      • - +
    • You define exceptions to those default policies in + the /etc/shorewall/rules file.
      • +
    - -

    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 three-interface sample + +

    The /etc/shorewall/policy file included with the three-interface sample has the following policies:

    - -
    + +
    - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    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 +

    + +
    +

    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
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    fwnetACCEPT  
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network +
    2. allow all connection requests from your local network to the internet
      3. -
    3. drop (ignore) all connection requests from the internet +
    4. drop (ignore) all connection requests from the internet to your firewall or local network
      5. -
    5. optionally accept all connection requests from the -firewall to the internet (if you uncomment the additional policy)
      6. -
    6. reject all other connection requests.
      7. - +
    7. optionally accept all connection requests from the + firewall to the internet (if you uncomment the additional policy)
      8. +
    8. reject all other connection requests.
      9. +
    - +

    -     At this point, edit your /etc/shorewall/policy file +     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. +

    + +

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

    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 DMZ Interface will also be an ethernet adapter + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your + DMZ computers will be connected to the same switch (note: If you have + only a single DMZ system, you can connect the firewall directly to the + computer using a cross-over cable).

    +

    - Do not connect more than one interface to the same - hub or switch (even for testing). It won't work the way that you -expect it to and you will end up confused and believing that Shorewall -doesn't work at all.

    - +     Do not connect more than one interface to the same + hub or switch (even for testing). It won't work the way that you expect + it to and you will end up confused and believing that Shorewall doesn't + work at all.

    +

    -     The Shorewall three-interface sample configuration assumes - that the external interface is eth0, the local interface is - eth1 and the DMZ interface is eth2. If your configuration - is different, you will have to modify the sample /etc/shorewall/interfaces - file accordingly. While you are there, you may wish to review the -list of options that are specified for the interfaces. Some hints:

    - +     The Shorewall three-interface sample configuration assumes + that the external interface is eth0, the local interface is + eth1 and the DMZ interface is eth2. If your configuration + is different, you will have to modify the sample /etc/shorewall/interfaces + file accordingly. While you are there, you may wish to review the list + of options that are specified for the interfaces. Some hints:

    +
      -
    • -

      If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-". -

      -
      • -
    • -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from +

    • +

      If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-". +

      +
      • +
    • +

      If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the option list.

      -
      • - + +
    - +

    IP Addresses

    - -

    Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you - a single Public IP address. This address may be assigned via - the Dynamic Host Configuration Protocol (DHCP) or as part of -establishing your connection when you dial in (standard modem) or establish -your PPP connection. In rare cases, your ISP may assign you a static -IP address; that means that you configure your firewall's external interface - to use that address permanently. Regardless of how the address - is assigned, it will be shared by all of your systems when you access -the Internet. You will have to assign your own addresses for your internal -network (the local and DMZ Interfaces on your firewall plus your other computers). -RFC 1918 reserves several Private IP address ranges for this purpose:

    - -
    + +

    Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you + a single Public IP address. This address may be assigned via + the Dynamic Host Configuration Protocol (DHCP) or as part of +establishing your connection when you dial in (standard modem) or establish +your PPP connection. In rare cases, your ISP may assign you a static +IP address; that means that you configure your firewall's external interface + to use that address permanently. Regardless of how the address + is assigned, it will be shared by all of your systems when you access +the Internet. You will have to assign your own addresses for your internal +network (the local and DMZ Interfaces on your firewall plus your other computers). + RFC 1918 reserves several Private IP address ranges for this purpose:

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

    -     Before starting Shorewall, you should look at the -IP address of your external interface and if it is one of the above - ranges, you should remove the 'norfc1918' option from the external +     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 +

    + +
    +

    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.

    -
    - -
    + href="shorewall_setup_guide.htm#Subnets">Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive "1" bits from + the left of the subnet mask.

    +
    + +

    Example sub-network:

    -
    - -
    -
    +
    + +
    +
    - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    -
    - -
    -

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above +

    + + +
    +

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

    + +
    +

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

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

    - -

    The remainder of this quide will assume that you have configured + +

    The remainder of this quide will assume that you have configured your network as shown here:

    - +

    -

    - -

    The default gateway for the DMZ computers would be 10.10.11.254 +

    + +

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

    - -

    -     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 Address Translation (NAT). The firewall rewrites the -source address in the packet to be the address of the firewall's external -interface; in other words, the firewall makes it look as if the firewall - itself is initiating the connection.  This is necessary so that the - destination host will be able to route return packets back to the firewall - (remember that packets whose destination address is reserved by RFC -1918 can't be routed accross the internet). When the firewall receives -a return packet, it rewrites the destination address back to 10.10.10.1 - and forwards the packet on to local computer 1.

    - -

    On Linux systems, the above process is often referred to -as IP Masquerading and you will also see the term Source Network -Address Translation (SNAT) used. Shorewall follows the convention used -with Netfilter:

    - -
      -
    • -

      Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

      -
      • -
    • -

      SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local - network to use.

      -
      • - -
    - -

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

    - -

    -     If your external firewall interface is eth0, your - local interface eth1 and your DMZ interface is eth2 -then you do not need to modify the file provided with the sample. Otherwise, - edit /etc/shorewall/masq and change it to match your configuration.

    - -

    -     If your external 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, +     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 +Address Translation (NAT). The firewall rewrites the source address +in the packet to be the address of the firewall's external interface; +in other words, the firewall makes it look as if the firewall itself +is initiating the connection.  This is necessary so that the destination +host will be able to route return packets back to the firewall (remember +that packets whose destination address is reserved by RFC 1918 can't + be routed accross the internet). When the firewall receives a return +packet, it rewrites the destination address back to 10.10.10.1 and forwards +the packet on to local computer 1.

    + +

    On Linux systems, the above process is often referred to as + IP Masquerading and you will also see the term Source Network Address + Translation (SNAT) used. Shorewall follows the convention used with + Netfilter:

    + +
      +
    • +

      Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

      +
      • +
    • +

      SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local + network to use.

      +
      • + +
    + +

    In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file.

    + +

    +     If your external firewall interface is eth0, +your local interface eth1 and your DMZ interface is eth2 +then you do not need to modify the file provided with the sample. Otherwise, + edit /etc/shorewall/masq and change it to match your configuration.

    + +

    +     If your external 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:
    -

    - +

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

    Port Forwarding (DNAT)

    - -

    One of your goals will be to run one or more servers on your - DMZ computers. Because these computers have RFC-1918 addresses, it - is not possible for clients on the internet to connect directly to -them. It is rather necessary for those clients to address their connection - requests to your firewall who rewrites the destination address to the - address of your server and forwards the packet to that server. When -your server responds, the firewall automatically performs SNAT to -rewrite the source address in the response.

    - -

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure -port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - -

    The general form of a simple port forwarding rule in /etc/shorewall/rules + +

    One of your goals will be to run one or more servers on your + DMZ computers. Because these computers have RFC-1918 addresses, it + is not possible for clients on the internet to connect directly to +them. It is rather necessary for those clients to address their connection + requests to your firewall who rewrites the destination address to the + address of your server and forwards the packet to that server. When your + server responds, the firewall automatically performs SNAT to rewrite + the source address in the response.

    + +

    The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure + port forwarding using DNAT rules in the /etc/shorewall/rules file.

    + +

    The general form of a simple port forwarding rule in /etc/shorewall/rules is:

    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - + + - - - - - - - + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server + DNATnetdmz:<server local ip address> [:<server port>]<protocol><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 +

    + +

    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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
    ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
    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).
      • - +
    • 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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000  
    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 +

    + +

    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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    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 +

    + +

    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. - +
    3. Include the following in /etc/shorewall/params:
      +
      + ETH0_IP=`find_interface_address eth0`
      +  
      4. +
    4. Make your loc->dmz rule:
      5. +
    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    -     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    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.

    - +
    + +

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

    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 your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers + or if those addresses are available on their web site, you can configure + your internal systems to use those addresses. If that information + isn't available, look in /etc/resolv.conf on your firewall system + -- the name servers are given in "nameserver" records in that file.

      -
      • -
    • +
      • +

    • -     You can configure a Caching Name Server on your - firewall or in your DMZ. Red Hat has an RPM for a caching -name server (which also requires the 'bind' RPM) and for Bering -users, there is dnscache.lrp. If you take this approach, you configure -your internal systems to use the caching name server as their primary -(and only) name server. You use the internal IP address of the firewall -(10.10.10.254 in the example above) for the name server address if -you choose to run the name server on your firewall. To allow your local -systems to talk to your caching name server, you must open port 53 -(both UDP and TCP) from the local network to the server; you do that -by adding the rules in /etc/shorewall/rules.

      -
      • - +     You can configure a Caching Name Server on your + firewall or in your DMZ. Red Hat has an RPM for a caching +name server (which also requires the 'bind' RPM) and for Bering users, + there is dnscache.lrp. If you take this approach, you configure your + internal systems to use the caching name server as their primary (and + only) name server. You use the internal IP address of the firewall (10.10.10.254 + in the example above) for the name server address if you choose to + run the name server on your firewall. To allow your local systems to +talk to your caching name server, you must open port 53 (both UDP +and TCP) from the local network to the server; you do that by adding +the rules in /etc/shorewall/rules.

      + +
    - -
    -

    If you run the name server on the firewall: + +

    +

    If you run the name server on the firewall: - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    -

    -
    - -
    -
    +

    +
    + +
    +

    Run name server on DMZ computer 1

    - + - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    -
    -
    - -
    +
    + + +

    Other Connections

    -
    - -
    +
    + +

    The three-interface sample includes the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    -
    -
    - -
    -

    Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy + +

    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy allowing all connections from the firewall to the internet.

    -
    - -
    +
    + +

    The sample also includes:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    -
    -
    - -
    -

    That rule allows you to run an SSH server on your firewall - and in each of your DMZ systems and to connect to those servers + +

    + +
    +

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

    + +
    +

    If you wish to enable other connections between your systems, the general format is:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    -
    -
    - -
    -

    Example - You want to run a publicly-available DNS server + +

    + +
    +

    Example - You want to run a publicly-available DNS server on your firewall system:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwudp
    +     		53#Allow DNS accessfrom the internet
    -
    -
    - -
    -

    Those two rules would of course be in addition to the rules + +

    + +
    +

    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:

    -
    - -
    -
    +
    + +
    +

    If you don't know what port and protocol a particular application + uses, look here.

    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you + want shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    + +
    + +

    - +

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible +     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 modify /etc/shorewall/rules to add or remove other - connections as required.

    -
    - -
    -

    Starting and Stopping Your Firewall

    +     Now modify /etc/shorewall/rules to add or remove +other connections as required.

    - -
    + +
    +

    Starting and Stopping Your Firewall

    +
    + +

    Arrow -     The installation procedure - configures your system to start Shorewall at system boot  but beginning -with Shorewall version 1.3.9 startup is disabled so that your system -won't try to start Shorewall before configuration is complete. Once you -have completed configuration of your firewall, you can enable Shorewall -startup by removing the file /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 + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
    -

    -
    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, +

    +
    + +
    +

    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 + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" + command. If you want to totally remove any trace of Shorewall from your Netfilter configuration, use "shorewall clear".

    -
    - -
    +
    + +

    -     The three-interface sample assumes that you want to enable - routing to/from eth1 (your local network) and eth2 (DMZ) - when Shorewall is stopped. If these two interfaces don't connect - to your local network and DMZ or if you want to enable a different - set of hosts, modify /etc/shorewall/routestopped accordingly.

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you - have added an entry for the IP address that you are connected from - to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to -create an alternate +     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.

    +
    + + - -

    Last updated 2/21/2003 - + +

    Last updated 5/19/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 - Thomas M. Eastep

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

    Copyright 2002, 2003 + Thomas M. Eastep
    +

    diff --git a/STABLE/documentation/three-interface_fr.html b/STABLE/documentation/three-interface_fr.html index 76d9e92d4..8571ef63f 100755 --- a/STABLE/documentation/three-interface_fr.html +++ b/STABLE/documentation/three-interface_fr.html @@ -1,1213 +1,1194 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    +

    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'à Tom EASTEP pour -son formidable outil et sa disponibilité).

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

    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 +
    • 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, +
    • 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' +

    + +

    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 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 situés dans le répertoire - /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec + 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 + href="Install.htm">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 + +

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

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

    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.

    - + - -

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

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

    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 +

    + +
    +

    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 l'Internet
      2. -
    2. drop (ignorer) toutes les demandes de connexion depuis l'Internet -vers votre firewall ou vers votre réseau local
      3. -
    3. Facultativement accepter toutes les demandes de connexion depuis -votre firewall et vers Internet (si vous decommentez la politique précédente)
      4. -
    4. reject (rejeter) toutes les autres demandes de connexion.
      5. - +
    5. permettre toutes demandes de connexion depuis le firewall vers +l'Internet
      6. +
    6. drop (ignorer) toutes les demandes de connexion depuis l'Internet + vers votre firewall ou vers votre réseau local
      7. +
    7. Facultativement accepter toutes les demandes de connexion depuis + votre firewall et vers Internet (si vous decommentez la politique précédente)
      8. +
    8. reject (rejeter) toutes les autres demandes de connexion.
      9. +
    - +

    - A ce point, éditez votre /etc/shorewall/policy et faites y les changements + 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 + 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 + +

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

    - + +

    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 +

    • +

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

    -
    - -
    +
    + +
    +

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

    + +

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

    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 +

    + +

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

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

    - + +

    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 +

    • +

      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 +

      • +
    • +

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

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

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

    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 +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server port>]<protocol><port>
    -
    -
    <protocol><port>
    +
    +
    -
    - -

    Si vous ne spécifiez pas le <server port>, il est supposé +

    + +

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

    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 +
    • 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 +
    • 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 + href="http://w.x.y.z:5000"> 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 +

    • +

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

    + +
    +

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

    + +
    +

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

    + +
    +

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

    + +
    +

    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
    ACCEPTnetfwtcp53#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) + +

    + +
    +

    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 +

    + +
    +

    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 +

    + +
    +

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

    +
    + +
    +

    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"; + 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 configuration alternativeet de la + href="configuration_file_basics.htm#Configs">alternativeet de la tester en utilisant la commande "shorewall try".

    -
    - -

    Last updated 12/20/2002 - + +

    Last updated 05/19/2003 - Tom Eastep

    - -

    Copyright 2002 Thomas - M. Eastep

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

    Copyright 2002, 2003 +Thomas M. Eastep
    +

    diff --git a/STABLE/documentation/two-interface.htm b/STABLE/documentation/two-interface.htm index ef6c48ab3..14192e6ff 100644 --- a/STABLE/documentation/two-interface.htm +++ b/STABLE/documentation/two-interface.htm @@ -1,1031 +1,1026 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
    +

    Basic Two-Interface Firewall

    -
    - -

    Setting up a Linux system as a firewall for a small network - is a fairly straight-forward task if you understand the basics -and follow the documentation.

    - -

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

    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.

    + +

    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:

    - +
      -
    • Linux system used as a firewall/router for a small +
    • Linux system used as a firewall/router for a small local network.
      • -
    • Single public IP address.
      • -
    • Internet connection through cable modem, DSL, ISDN, +
    • 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" +

    + +

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

    - -

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

    - -

    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:

    - +

    + +

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

    + +

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

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

    - +

    +

    -     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 two-interface sample, - un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to +     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).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration + +

    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 two-interface sample configuration, + +

    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:

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

    Zones are defined in the /etc/shorewall/zones + +

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

    - -

    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.

    - +
      -
    • You express your default policy for connections +
    • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
      • -
    • You define exceptions to those default policies +
    • You define exceptions to those default policies in the /etc/shorewall/rules file.
      • - +
    - -

    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 two-interface sample -has the following policies:

    - -
    + +

    The /etc/shorewall/policy file included with the two-interface sample has +the following policies:

    + +
    - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    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 +

    + +
    +

    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.

    - + - + + + + + + + + - - - - - - - - - - - - - - - + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    fwnetACCEPT  
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network +
    2. allow all connection requests from your local network to the internet
      3. -
    3. drop (ignore) all connection requests from the internet - to your firewall or local network
      4. -
    4. optionally accept all connection requests from the - firewall to the internet (if you uncomment the additional policy)
      5. -
    5. reject all other connection requests.
      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 +     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. +

    + +

    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.

    - +

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

    - -

    Your Internal Interface will be an ethernet adapter - (eth1 or eth0) and will be connected to a hub or switch. Your other - computers will be connected to the same hub/switch (note: If you -have only a single internal system, you can connect the firewall -directly to the computer using a cross-over cable).

    - + +

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

    +

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

      -
      • -
    • -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from +

    • +

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

    - -
    + +

    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:

    + +
         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 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, +     Before starting Shorewall, you should look at the + IP address of your external interface and if it is one of the above + ranges, you should remove the 'norfc1918' option from the external + interface's entry in /etc/shorewall/interfaces.

    +
    + +
    +

    You will want to assign your addresses from the same +sub-network (subnet).  For our purposes, we can consider a subnet + to consists of a range of addresses x.y.z.0 - x.y.z.255. Such +a subnet will have a Subnet Mask of 255.255.255.0. The address + x.y.z.0 is reserved as the Subnet Address and x.y.z.255 is + reserved as the Subnet Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing - (CIDR) notation with consists of the subnet address followed - by "/24". The "24" refers to the number of consecutive leading "1" + href="shorewall_setup_guide.htm#Subnets">Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive leading "1" bits from the left of the subnet mask.

    -
    - -
    +
    + +

    Example sub-network:

    -
    - -
    -
    +
    + +
    +
    - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    -
    - -
    -

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above + +

    + +
    +

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

    + +
    +

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

    - -

    The remainder of this quide will assume that you have configured +

    + +

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

    + +

    The remainder of this quide will assume that you have configured your network as shown here:

    - +

    -

    - +

    +

    The default gateway for 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 +     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 + +

    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.

    - -

    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:

    - + +

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

    • +

      Masquerade describes the case where you let your + firewall system automatically detect the external interface address.

      -
      • -
    • -

      SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local +

      • +
    • +

      SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local network to use.

      -
      • - + +
    - -

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. You will normally use -Masquerading if your external IP is dynamic and SNAT if the IP -is static.

    - + +

    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.

    +

    -     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 +     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, +     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
      • +
    • IP_FORWARDING=On
      +
      • +
    - +

    Port Forwarding (DNAT)

    - -

    One of your goals may be to run one or more servers on your - local computers. Because these computers have RFC-1918 addresses, - it is not possible for clients on the internet to connect directly -to them. It is rather necessary for those clients to address their -connection requests to the firewall who rewrites the destination address -to the address of your server and forwards the packet to that server. -When your server responds, the firewall automatically performs SNAT -to rewrite the source address in the response.

    - -

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure + +

    One of your goals may be to run one or more servers on your + local computers. Because these computers have RFC-1918 addresses, + it is not possible for clients on the internet to connect directly +to them. It is rather necessary for those clients to address their connection + requests to the firewall who rewrites the destination address to the + address of your server and forwards the packet to that server. When + your server responds, the firewall automatically performs SNAT to rewrite + the source address in the response.

    + +

    The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - -

    The general form of a simple port forwarding rule in /etc/shorewall/rules + +

    The general form of a simple port forwarding rule in /etc/shorewall/rules is:

    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - + + - - - - - - - + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:<server local ip address> [:<server + DNATnetloc:<server local ip address> [:<server port>]<protocol><port>  
    <protocol><port>  
    -
    - -

    Example - you run a Web Server on computer 2 and you want to forward incoming +

    + +

    Example - you run a Web Server on computer 2 and you want to forward incoming TCP port 80 to that system:

    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2tcp80  
    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 +
    • 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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2:80tcp5000  
    DNATnetloc:10.10.10.2:80tcp5000  
    -
    - +
    +

    -     At this point, modify /etc/shorewall/rules to add +     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:

    - + +

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

      -
      • - +     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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    -
    - -
    +
    + +

    Other Connections

    -
    - -
    +
    + +

    The two-interface sample includes the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnettcp53  
    ACCEPTfwnetudp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnettcp53  
    ACCEPTfwnetudp53  
    -
    + +
    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you uncommented the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

    - -
    -

    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  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    -
    -
    - -
    -

    That rule allows you to run an SSH server on your firewall + +

    + +
    +

    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 +

    + +
    +

    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>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    -
    + +
    + +
    +

    Example - You want to run a Web Server on your firewall +system:

    - -
    -

    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 +

    +
    + +
    +

    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"

    -
    - -
    -

    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 +

    + +
    +

    If you don't know what port and protocol a particular application + uses, look here.

    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you want shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    + +
    + +

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible +     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.

    -
    - -
    -

    Starting and Stopping Your Firewall

    + +     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 +     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 + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
    -

    -
    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, +

    +
    + +
    +

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

    -
    - -
    + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" + command. If you want to totally remove any trace of Shorewall from + your Netfilter configuration, use "shorewall clear".

    +
    + +

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

    + + - +
    +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Eastep
    -

    -
    -
    -
    -
    +

    diff --git a/STABLE/documentation/upgrade_issues.htm b/STABLE/documentation/upgrade_issues.htm index b721cc87a..bce12679d 100644 --- a/STABLE/documentation/upgrade_issues.htm +++ b/STABLE/documentation/upgrade_issues.htm @@ -1,421 +1,441 @@ - + Upgrade Issues - + - + - + - + - - - + + - - - + + + +
    +
    +

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

    - +

    + +

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

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

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

    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:
    - -
      -
    • 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:
    - -
      -
    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. - -
    - 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?
    - -
    	[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
    - -     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:
    -
    - -
    - 
    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.
    - -

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

    - -

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

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

    - -

    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 forget - to backup root.lrp !
      4. - -
    - -

    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

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

    Versions >= 1.3.5

    - -

    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 4/13/2003 - Tom -Eastep

    - -

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

    -
    +

    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
    +

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

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

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

    + +

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

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

    + +

    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 +forget to backup root.lrp !
      4. + +
    + +

    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

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

    Versions >= 1.3.5

    + +

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

    diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index c0e2744cd..8f2c746b0 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.3a +VERSION=1.4.4a usage() # $1 = exit status { diff --git a/STABLE/firewall b/STABLE/firewall index b20fc8b84..5eae0f2a3 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -904,6 +904,55 @@ run_user_exit() # $1 = file name fi } +# +# Add a logging rule. +# +log_rule() # $1 = log level, $2 = chain, $3 = disposition , $... = predicates for the rule +{ + local level=$1 + local chain=$2 + local disposition=$3 + local rulenum= + + shift;shift;shift + + if [ -n "$LOGRULENUMBERS" ]; then + eval rulenum=\$${chain}_logrules + + [ -z "$rulenum" ] && rulenum=1 + + case $level in + ULOG) + eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' + ;; + *) + eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $rulenum $disposition`"' + ;; + esac + + if [ $? -ne 0 ] ; then + [ -z "$stopping" ] && { stop_firewall; exit 2; } + fi + + rulenum=$(($rulenum + 1)) + + eval ${chain}_logrules=$rulenum + else + case $level in + ULOG) + eval iptables -A $chain $@ -j ULOG $LOGPARMS --ulog-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' + ;; + *) + eval iptables -A $chain $@ -j LOG $LOGPARMS --log-prefix '"`printf "$LOGFORMAT" $chain $disposition`"' + ;; + esac + + if [ $? -ne 0 ] ; then + [ -z "$stopping" ] && { stop_firewall; exit 2; } + fi + fi +} + # # Stop the Firewall # @@ -1281,18 +1330,6 @@ setup_mac_lists() { fi done < $TMP_DIR/maclist # - # Setup Logging variables - # - if [ -n "$MACLIST_LOG_LEVEL" ]; then - if [ "$MACLIST_LOG_LEVEL" = ULOG ]; then - logpart="-j ULOG $LOGPARMS --ulog-prefix" - else - logpart="-j LOG $LOGPARMS --log-level $MACLIST_LOG_LEVEL --log-prefix" - fi - else - logpart= - fi - # # Must take care of our own broadcasts and multicasts then terminate the verification # chains # @@ -1322,8 +1359,9 @@ setup_mac_lists() { shift done - [ -n "$logpart" ] && \ - run_iptables -A $chain $logpart "${LOGMARKER}$chain:$MACLIST_DISPOSITION:" + if [ -n "$MACLIST_LOG_LEVEL" ]; then + log_rule $MACLIST_LOG_LEVEL $chain $MACLIST_DISPOSITION + fi run_iptables -A $chain -j $maclist_target done @@ -1832,6 +1870,13 @@ add_nat_rule() { fi for adr in $addr; do + if [ -n "$loglevel" ]; then + ensurenatchain $chain + log_rule $loglevel $chain $logtarget -t nat \ + `fix_bang $proto $cli $sports -d $adr $multiport $dports` + loglevel= + fi + addnatrule $chain $proto $cli $sports \ -d $adr $multiport $dports -j $target1 done @@ -2017,21 +2062,11 @@ add_a_rule() if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then serv="${serv:+-d $serv}" - if [ -n "$loglevel" ]; then - if [ "$loglevel" = ULOG ]; then - run_iptables2 -A $chain $proto $multiport \ - $state $cli $sports $serv $dports -j ULOG $LOGPARMS \ - --ulog-prefix "${LOGMARKER}$chain:$logtarget:" - else - run_iptables2 -A $chain $proto $multiport \ - $state $cli $sports $serv $dports -j LOG $LOGPARMS \ - --log-prefix "${LOGMARKER}$chain:$logtarget:" \ - --log-level $loglevel - fi + log_rule $loglevel $chain $logtarget \ + `fix_bang $proto $sports $multiport $state $cli $serv $dports` fi - run_iptables2 -A $chain $proto $multiport $state $cli $sports \ $serv $dports -j $target fi @@ -2046,16 +2081,8 @@ add_a_rule() if [ $command != check ]; then if [ -n "$loglevel" ]; then - if [ "$loglevel" = ULOG ]; then - run_iptables2 -A $chain $proto $multiport \ - $dest_interface $state $cli $sports $dports -j ULOG \ - $LOGPARMS --ulog-prefix "${LOGMARKER}$chain:$logtarget:" - else - run_iptables2 -A $chain $proto $multiport \ - $dest_interface $state $cli $sports $dports -j LOG \ - $LOGPARMS --log-prefix "${LOGMARKER}$chain:$logtarget:" \ - --log-level $loglevel - fi + log_rule $loglevel $chain $logtarget \ + `fix_bang $proto $multiport $dest_interface $state $cli $sports $dports` fi if [ $logtarget != LOG ]; then @@ -2123,6 +2150,17 @@ process_rule() # $1 = target servers="$FW::$servers" fi ;; + REDIRECT-) + target=ACCEPT + logtarget=REDIRECT + dnat_only=Yes + address=${address:=all} + if [ "x-" = "x$servers" ]; then + servers=$FW + else + servers="$FW::$servers" + fi + ;; esac # Parse and validate source @@ -2263,7 +2301,7 @@ process_rules() # $1 = name of rules file while read xtarget xclients xservers xprotocol xports xcports xaddress; do case "${xtarget%:*}" in - ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|LOG|CONTINUE) + ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|REDIRECT-|LOG|CONTINUE) expandv xclients xservers xprotocol xports xcports xaddress if [ "x$xclients" = xall ]; then @@ -2556,13 +2594,7 @@ policy_rules() # $1 = chain to add rules to esac if [ $# -eq 3 -a "x${3}" != "x-" ]; then - if [ "$3" = ULOG ]; then - run_iptables -A $1 -j ULOG $LOGPARMS \ - --ulog-prefix "${LOGMARKER}${1}:${2}:" - else - run_iptables -A $1 -j LOG $LOGPARMS \ - --log-prefix "${LOGMARKER}${1}:${2}:" --log-level $3 - fi + log_rule $3 $1 $2 fi [ -n "$target" ] && run_iptables -A $1 -j $target @@ -2882,16 +2914,7 @@ setup_masq() # add_blacklist_rule() { if [ -n "$BLACKLIST_LOGLEVEL" ]; then - if [ "$BLACKLIST_LOGLEVEL" = ULOG ]; then - run_iptables2 -A blacklst $source $proto $dport -j \ - ULOG $LOGPARMS --ulog-prefix \ - "${LOGMARKER}blacklst:$BLACKLIST_DISPOSITION:" - else - run_iptables2 -A blacklst $source $proto $dport -j \ - LOG $LOGPARMS --log-prefix \ - "${LOGMARKER}blacklst:$BLACKLIST_DISPOSITION:" \ - --log-level $BLACKLIST_LOGLEVEL - fi + log_rule $BLACKLIST_LOGLEVEL blacklst $BLACKLIST_DISPOSITION `fix_bang $source $proto $dport` fi run_iptables2 -A blacklst $source $proto $dport -j $disposition @@ -3227,13 +3250,7 @@ initialize_netfilter () { createchain newnotsyn no run_user_exit newnotsyn if [ -n "$LOGNEWNOTSYN" ]; then - if [ "$LOGNEWNOTSYN" = ULOG ]; then - run_iptables -A newnotsyn -j ULOG $LOGPARMS \ - --ulog-prefix "${LOGMARKER}newnotsyn:DROP:" - else - run_iptables -A newnotsyn -j LOG $LOGPARMS \ - --log-prefix "${LOGMARKER}newnotsyn:DROP:" --log-level $LOGNEWNOTSYN - fi + log_rule $LOGNEWNOTSYN newnotsyn DROP fi run_iptables -A newnotsyn -j DROP @@ -3304,14 +3321,7 @@ build_common_chain() { # Construct zone-independent rules # add_common_rules() { - logdisp() # $1 = Chain Name - { - if [ "$RFC1918_LOG_LEVEL" = ULOG ]; then - echo "ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}${1}:DROP:" - else - echo "LOG $LOGPARMS --log-prefix ${LOGMARKER}${1}:DROP: --log-level $RFC1918_LOG_LEVEL" - fi - } + local savelogparms="$LOGPARMS" # # Reject Rules # @@ -3336,16 +3346,16 @@ add_common_rules() { createchain badpkt no if [ -n "$LOGUNCLEAN" ]; then - if [ "$LOGUNCLEAN" = ULOG ]; then - logoptions="-j ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}badpkt:DROP:" - logoptions="$logoptions --log-ip-options" - else - logoptions="-j LOG $LOGPARMS --log-prefix ${LOGMARKER}badpkt:DROP:" - logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" - fi + + LOGPARMS="$LOGPARMS --log-ip-options" - run_iptables -A badpkt -p tcp $logoptions --log-tcp-options - run_iptables -A badpkt -p ! tcp $logoptions + log_rule $LOGUNCLEAN badpkt DROP -p ! tcp + + LOGPARMS="$LOGPARMS --log-tcp-options" + + log_rule $LOGUNCLEAN badpkt DROP -p tcp + + LOGPARMS="$savelogparms" fi run_iptables -A badpkt -j DROP @@ -3368,16 +3378,15 @@ add_common_rules() { [ -z"$LOGUNCLEAN" ] && LOGUNCLEAN=info - if [ "$LOGUNCLEAN" = ULOG ]; then - logoptions="-j ULOG $LOGPARMS --ulog-prefix ${LOGMARKER}logpkt:LOG:" - logoptions="$logoptions --log-ip-options" - else - logoptions="-j LOG $LOGPARMS --log-prefix ${LOGMARKER}logpkt:LOG:" - logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options" - fi + LOGPARMS="$LOGPARMS --log-ip-options" - run_iptables -A logpkt -p tcp $logoptions --log-tcp-options - run_iptables -A logpkt -p ! tcp $logoptions + log_rule $LOGUNCLEAN logpkt DROP -p ! tcp + + LOGPARMS="$LOGPARMS --log-tcp-options" + + log_rule $LOGUNCLEAN logpkt DROP -p tcp + + LOGPARMS="$savelogparms" echo "Mangled/Invalid Packet Logging enabled on:" @@ -3414,7 +3423,9 @@ add_common_rules() { createchain rfc1918 no createchain logdrop no - run_iptables -A logdrop -j `logdisp rfc1918` + + log_rule $RFC1918_LOG_LEVEL logdrop DROP + run_iptables -A logdrop -j DROP if [ -n "$MANGLE_ENABLED" ]; then @@ -3427,7 +3438,7 @@ add_common_rules() { # run_iptables -t mangle -N man1918 run_iptables -t mangle -N logdrop - run_iptables -t mangle -A logdrop -j `logdisp man1918` + log_rule $RFC1918_LOG_LEVEL logdrop DROP -t mangle run_iptables -t mangle -A logdrop -j DROP fi @@ -3471,16 +3482,14 @@ add_common_rules() { if [ -n "$TCP_FLAGS_LOG_LEVEL" ]; then createchain logflags no - if [ "$TCP_FLAGS_LOG_LEVEL" = ULOG ]; then - run_iptables -A logflags -j ULOG $LOGPARMS \ - --ulog-prefix "${LOGMARKER}logflags:$TCP_FLAGS_DISPOSITION:" \ - --log-tcp-options --log-ip-options - else - run_iptables -A logflags -j LOG $LOGPARMS \ - --log-level $TCP_FLAGS_LOG_LEVEL \ - --log-prefix "${LOGMARKER}logflags:$TCP_FLAGS_DISPOSITION:" \ - --log-tcp-options --log-ip-options - fi + savelogparms="$LOGPARMS" + + LOGPARMS="$LOGPARMS --log-ip-options" + + log_rule $TCP_FLAGS_LOG_LEVEL logflags $TCP_FLAGS_DISPOSITION + + LOGPARMS="$savelogparms" + case $TCP_FLAGS_DISPOSITION in REJECT) run_iptables -A logflags -j REJECT --reject-with tcp-reset @@ -4344,7 +4353,8 @@ do_initialize() { SHARED_DIR=/usr/share/shorewall FUNCTIONS= VERSION_FILE= - LOGMARKER= + LOGFORMAT= + LOGRULENUMBERS= stopping= have_mutex= @@ -4470,9 +4480,27 @@ do_initialize() { else CLEAR_TC= fi + + if [ -n "$LOGFORMAT" ]; then + if [ -n "`echo $LOGFORMAT | grep '%d'`" ]; then + LOGRULENUMBERS=Yes + temp=`printf "$LOGFORMAT" fooxx 1 barxx 2> /dev/null` + if [ $? -ne 0 ]; then + startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\"" + fi + else + temp=`printf "$LOGFORMAT" fooxx barxx 2> /dev/null` + if [ $? -ne 0 ]; then + startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\"" + fi + fi - [ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:" - + if [ ${#temp} -gt 29 ]; then + startup_error "LOGFORMAT string is too long: \"$LOGFORMAT\"" + fi + else + LOGFORMAT="Shorewall:%s:%s:" + fi # # Strip the files that we use often # diff --git a/STABLE/install.sh b/STABLE/install.sh index 8d5a62d45..09b6691a0 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.3a +VERSION=1.4.4a usage() # $1 = exit status { diff --git a/STABLE/releasenotes.txt b/STABLE/releasenotes.txt index 48c70abe5..efa8ced70 100644 --- a/STABLE/releasenotes.txt +++ b/STABLE/releasenotes.txt @@ -2,36 +2,32 @@ This is a minor release of Shorewall. Problems Corrected: -1) There were several cases where Shorewall would fail to remove a - temporary directory from /tmp. These cases have been corrected. - -2) The rules for allowing all traffic via the loopback interface have - been moved to before the rule that drops status=INVALID - packets. This insures that all loopback traffic is allowed even if - Netfilter connection tracking is confused. - New Features: -1) IPV6-IPV4 (6to4) tunnels are now supported in the - /etc/shorewall/tunnels file. +1) A REDIRECT- rule target has been added. This target behaves for + REDIRECT in the same was as DNAT- does for DNAT in that the + Netfilter nat table REDIRECT rule is added but not the companion + filter table ACCEPT rule. -2) Shorewall can now be easily integrated with fireparse - (http://www.fireparse.com) by setting LOGMARKER="fp=" in - /etc/shorewall/shorewall.conf. Note: You may not use ULOG - with fireparse unless you modify fireparse. +2) The LOGMARKER variable has been renamed LOGFORMAT and has been + changed to a 'printf' formatting template which accepts three + arguments (the chain name, logging rule number (optional) and the + disposition). The logging rule number is included if the LOGFORMAT + value contains '%d'. For example, to use LOGFORMAT with fireparse, + set it as: -3) If you are running iptables 1.2.7a and kernel 2.4.20, then - Shorewall will return reject replies as follows: + LOGFORMAT="fp=%s:%d a=%s " - a) tcp - RST - b) udp - ICMP port unreachable - c) icmp - ICMP host unreachable - d) Otherwise - ICMP host prohibited - If you are running earlier software, Shorewall will follow it's - traditional convention: + CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT + string (up to but not including the first '%') to find log messages + in the 'show log', 'status' and 'hits' commands. This part should + not be omitted (the LOGFORMAT should not begin with "%") and the + leading part should be sufficiently unique for /sbin/shorewall to + identify Shorewall messages. - a) tcp - RST - b) Otherwise - ICMP port unreachable +3) When logging is specified on a DNAT[-] or REDIRECT[-] rule, the + logging now takes place in the nat table rather than in the filter + table. This way, only those connections that actually undergo DNAT + or redirection will be logged. -4) UDP Port 135 is now silently dropped in the common.def chain. diff --git a/STABLE/shorewall b/STABLE/shorewall index 5a291f8b4..44c9cc5db 100755 --- a/STABLE/shorewall +++ b/STABLE/shorewall @@ -135,7 +135,9 @@ get_config() { [ -n "$FW" ] || FW=fw - [ -n "$LOGMARKER" ] || LOGMARKER="Shorewall:" + [ -n "LOGFORMAT" ] && LOGFORMAT="${LOGFORMAT%%%*}" + + [ -n "$LOGFORMAT" ] || LOGFORMAT="Shorewall:" } # @@ -261,9 +263,9 @@ packet_log() # $1 = number of messages [ -n "$realtail" ] && options="-n$1" - grep "${LOGMARKER}\|ipt_unclean" $LOGFILE | \ + grep "${LOGFORMAT}\|ipt_unclean" $LOGFILE | \ sed s/" kernel:"// | \ - sed s/" $host $LOGMARKER"/" "/ | \ + sed s/" $host $LOGFORMAT"/" "/ | \ sed s/" $host kernel: ipt_unclean: "/" "/ | \ sed 's/MAC=.*SRC=/SRC=/' | \ tail $options @@ -734,27 +736,27 @@ case "$1" in timeout=30 - if [ `grep -c "$LOGMARKER" $LOGFILE ` -gt 0 ] ; then + if [ `grep -c "$LOGFORMAT" $LOGFILE ` -gt 0 ] ; then echo " HITS IP DATE" echo " ---- --------------- ------" - grep "$LOGMARKER" $LOGFILE | sed 's/\(.\{6\}\)\(.*SRC=\)\(.*\)\( DST=.*\)/\3 \1/' | sort | uniq -c | sort -rn + grep "$LOGFORMAT" $LOGFILE | sed 's/\(.\{6\}\)\(.*SRC=\)\(.*\)\( DST=.*\)/\3 \1/' | sort | uniq -c | sort -rn echo "" echo " HITS IP PORT" echo " ---- --------------- -----" - grep "$LOGMARKER" $LOGFILE | sed 's/\(.*SRC=\)\(.*\)\( DST=.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2 \4/ + grep "$LOGFORMAT" $LOGFILE | sed 's/\(.*SRC=\)\(.*\)\( DST=.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2 \4/ t s/\(.*SRC=\)\(.*\)\( DST=.*\)/\2/' | sort | uniq -c | sort -rn echo "" echo " HITS DATE" echo " ---- ------" - grep "$LOGMARKER" $LOGFILE | sed 's/\(.\{6\}\)\(.*\)/\1/' | sort | uniq -c | sort -rn + grep "$LOGFORMAT" $LOGFILE | sed 's/\(.\{6\}\)\(.*\)/\1/' | sort | uniq -c | sort -rn echo "" echo " HITS PORT SERVICE(S)" echo " ---- ----- ----------" - grep '${LOGMARKER}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \ + grep '${LOGFORMAT}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \ while read count port ; do # List all services defined for the given port srv=`grep "^[^#].*\\b$port/" /etc/services | cut -f 1 | sort -u` diff --git a/STABLE/shorewall.conf b/STABLE/shorewall.conf index 2aa7ac989..3bc30551e 100644 --- a/STABLE/shorewall.conf +++ b/STABLE/shorewall.conf @@ -55,13 +55,30 @@ LOGFILE=/var/log/messages # -# LOG MARKER +# LOG FORMAT # -# Used to identify Shorewall log messages. If you are using fireparse, you must -# set this to "fp=Shorewall:". You may not use the ULOG level with fireparse and -# you must not embed white space in the LOGMARKER value. +# Shell 'printf' Formatting template for the --log-prefix value in log messages +# generated by Shorewall to identify Shorewall log messages. The supplied +# template is expected to accept either two or three arguments; the first is +# the chain name, the second (optional) is the logging rule number within that +# chain and the third is the ACTION specifying the disposition of the packet +# being logged. You must use the %d formatting type for the rule number; if your +# template does not contain %d then the rule number will not be included. +# +# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as: +# +# LOGFORMAT="fp=%s:%d a=%s " +# +# If not specified or specified as empty (LOGFORMAT="") then the value +# "Shorewall:%s:%s:" is assumed. +# +# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up +# to but not including the first '%') to find log messages in the 'show log', +# 'status' and 'hits' commands. This part should not be omitted (the +# LOGFORMAT should not begin with "%") and the leading part should be +# sufficiently unique for /sbin/shorewall to identify Shorewall messages. -LOGMARKER="Shorewall:" +LOGFORMAT="Shorewall:%s:%s:" # # LOG RATE LIMITING diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index 77d3ed105..8fad31c0d 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.4.3a +%define version 1.4.4a %define release 1 %define prefix /usr @@ -105,6 +105,10 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Tue May 27 2003 Tom Eastep +- Changed version to 1.4.4a-1 +* Thu May 22 2003 Tom Eastep +- Changed version to 1.4.4-1 * Mon May 19 2003 Tom Eastep - Changed version to 1.4.3a-1 * Sun May 18 2003 Tom Eastep diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index fa6541f73..e38f3710d 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.3a +VERSION=1.4.4a usage() # $1 = exit status { diff --git a/STABLE/zones b/STABLE/zones index e9b882473..4f3cdcd6f 100644 --- a/STABLE/zones +++ b/STABLE/zones @@ -3,7 +3,7 @@ # # This file determines your network zones. Columns are: # -# ZONE Short name of the zone +# ZONE Short name of the zone (5 Characters or less in length). # DISPLAY Display name of the zone # COMMENTS Comments about the zone # diff --git a/Shorewall-docs/6to4.htm b/Shorewall-docs/6to4.htm index eafd1d301..13c232288 100755 --- a/Shorewall-docs/6to4.htm +++ b/Shorewall-docs/6to4.htm @@ -1,141 +1,143 @@ - + 6to4 Tunnels - + - + - + - - - + + - - - + + + +
    +

    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 +

    + +

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

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

    + +

    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.

    - + +

    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 - encapsulation protocol (41) will be accepted to/from the remote gateway.

    - +
    + +

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

    - + +

    Updated 5/18/2003 - Tom Eastep +

    +

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

    -
    + size="2">2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.

    +
    +

    diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index 5d9b6761e..fd1e8500f 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -1,2947 +1,3014 @@ - + - + - + Shorewall 1.4 Documentation - + - + - + - + - - - + + - - - + + + +
    - +
    +

    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 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.
      -
      • -
    • masq - - This file also describes IP masquerading under Shorewall - and is installed in /etc/shorewall.
      • -
    • firewall -- a shell - program that reads the configuration files in /etc/shorewall - and configures your firewall. This file is installed - in your init.d directory (/etc/rc.d/init.d ) where -it is renamed shorewall. /etc/shorewall/firewall - (/var/lib/shorewall/firewall in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall - in 1.3.9 and later) is a symbolic link to this program.
      • -
    • nat - -- a parameter file in /etc/shorewall used to define 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.
      +
      • +
    • masq + - This file also describes IP masquerading under Shorewall + and is installed in /etc/shorewall.
      • +
    • firewall -- a shell + program that reads the configuration files in /etc/shorewall + and configures your firewall. This file is installed + in your init.d directory (/etc/rc.d/init.d ) where + it is renamed shorewall. /etc/shorewall/firewall + (/var/lib/shorewall/firewall in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall + in 1.3.9 and later) is a symbolic link to this program.
      • +
    • nat + -- a parameter file in /etc/shorewall used to define static NAT .
      • -
    • proxyarp - -- a parameter file in /etc/shorewall used to define Proxy Arp .
      • -
    • rfc1918 - -- a parameter file in /etc/shorewall used to define the - treatment of packets under the norfc1918 - interface option.
      • -
    • routestopped - -- a parameter file in /etc/shorewall used to define -those hosts that can access the firewall when Shorewall -is stopped.
      • -
    • tcrules -- a parameter - file in /etc/shorewall used to define rules for classifying - packets for Traffic Shaping/Control.
      • -
    • tunnels - -- a parameter file in /etc/shorewall used to define IPSec - tunnels.
      • -
    • shorewall - -- a shell program (requiring a Bourne shell or - derivative) used to control and monitor the firewall. - This should be placed in /sbin or in /usr/sbin (the -install.sh script and the rpm install this file in /sbin).
      • -
    • version -- a file -created in /etc/shorewall/ (/var/lib/shorewall -in version 1.3.2-1.3.8 and /usr/lib/shorewall beginning in -version 1.3.9) that describes the version of Shorewall - installed on your system.
      • - -
    - -

    /etc/shorewall/params

    - -

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

    - -

    It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - 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.

    - -

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

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

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

    - - - - - - - - - - - - - - - - - - - - - - - +
  • proxyarp -- a parameter file in + /etc/shorewall used to define Proxy Arp + .
    • +
  • rfc1918 + -- a parameter file in /etc/shorewall used to define the + treatment of packets under the norfc1918 + interface option.
    • +
  • routestopped -- a parameter + file in /etc/shorewall used to define those hosts that can + access the firewall when Shorewall is stopped.
    • +
  • tcrules -- a +parameter file in /etc/shorewall used to define rules for classifying + packets for Traffic Shaping/Control.
    • +
  • tunnels -- a parameter file in +/etc/shorewall used to define IPSec tunnels.
    • +
  • shorewall -- a shell program + (requiring a Bourne shell or derivative) used to + control and monitor the firewall. This should be placed in + /sbin or in /usr/sbin (the install.sh script and the +rpm install this file in /sbin).
    • +
  • version -- a +file created in /etc/shorewall/ (/var/lib/shorewall + in version 1.3.2-1.3.8 and /usr/lib/shorewall beginning +in version 1.3.9) that describes the version of Shorewall + installed on your system.
    • - -
    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.

    - -

    Warning 1: If you rename or delete a zone, you should perform "shorewall - 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.

    - -

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

    - + + +

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

    + +

    It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally + 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.

    + +

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

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

    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.

    + +

    Warning 1: If you rename or delete a zone, you should perform "shorewall + 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.

    + +

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

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

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

      - -

      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.

      - -

      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.

      - -

      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.

      - -

      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.

      - -

      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 +

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

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

      + +

      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.

      + +

      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.

      + +

      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.

      + +

      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.

      + +

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

      - -

      logunclean - This option works like dropunclean - with the exception that packets selected - by the 'unclean' match target in iptables - are logged but not dropped. -The level at which the packets are logged is determined by - the setting of LOGUNCLEAN and + href="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean1.patch">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.

      - -

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

    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:

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

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

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

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

    /etc/shorewall/hosts - 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. - -
    - 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:
      • - -
    - -
    -
      -
    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. - -
    - -

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

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

    -
    - -

    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.

    - -

    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.

    - -

    Example 1:

    - -

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

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

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

    - -

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

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

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

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

    - -
    - - - - - - - - - - - - - - - - - - - - - -
    ZONE HOST(S) OPTIONS
    loceth1:192.168.1.0/25
    -
    loceth1: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.

    - -

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

    - -

    /etc/shorewall/policy - Configuration.

    - -

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

    - -

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

    - -

    Four policies are defined:

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

    - -

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

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

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

    - -

    The policy file installed by default is as follows:

    - -
    - - - - - - - - - - - - - - - - - - + + + + + + + - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    -
    -
    ZONE INTERFACE BROADCAST OPTIONS
    netallDROPinfo
    -
    allallREJECTinfo
    -
    neteth0detectdhcp,norfc1918,blacklist
    loceth1detect
    +
    -
    - -

    This table may be interpreted as follows:

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

    WARNING:

    - -

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

    - -
    +
    + +

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

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
    locallACCEPT
    -
    -
    netallDROPinfo
    -
    loclocREJECTinfo
    -
    ZONE INTERFACE BROADCAST OPTIONS
    netppp0
    +
    +
    -
    - -

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

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

    - +
    + +

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

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

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

    The CONTINUE - policy

    - -

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

    - -

    /etc/shorewall/zones:

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

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

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

    +
    + +

    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.

    + +

    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.

    + +

    Example 1:

    + +

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

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

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

    + +

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

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

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

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

    + +
    + + + + + + + + + + + + + + + + + + + + + +
    ZONE HOST(S) OPTIONS
    loceth1:192.168.1.0/25
    +
    loceth1: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.

    + +

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

    + +

    /etc/shorewall/policy + Configuration.

    + +

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

    + +

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

    + +

    Four policies are defined:

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

    + +

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

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

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

    + +

    The policy file installed by default is as follows:

    + +
    + + + + - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE DISPLAY COMMENTS
    samSamSam's system at home
    netInternetThe Internet
    locLocLocal Network
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    +
    +
    netallDROPinfo
    +
    allallREJECTinfo
    +
    -
    - +
    + +

    This table may be interpreted as follows:

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

    WARNING:

    + +

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

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
    locallACCEPT
    +
    +
    netallDROPinfo
    +
    loclocREJECTinfo
    +
    +
    + +

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

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

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

    The CONTINUE + policy

    + +

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

    + +

    /etc/shorewall/zones:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE DISPLAY COMMENTS
    samSamSam's system at home
    netInternetThe Internet
    locLocLocal Network
    +
    +

    /etc/shorewall/interfaces:

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

    /etc/shorewall/hosts:

    - +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + +
    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.

    - + + +

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

    +

    /etc/shorewall/policy:

    - +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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).

    - + + +

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

    +

    Partial /etc/shorewall/rules:

    - +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ...
    -
    -
    -
    -
    -
    -
    DNATsamloc:192.168.1.3tcpssh-
    -
    DNATnetloc:192.168.1.5tcpwww-
    -
    ...
    -
    -
    -
    -
    -
    -
    -
    - -

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

    - -

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

    - -
    -

    - - - - - - - - - - - + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ...
    +
    +
    +
    +
    +
    +

    -
    -
    -
    -
    -
    -
    -
    ...
    -
    -
    -
    -
    -
    -
    DNATsamfwtcpssh-
    -
    DNATnet!samloc:192.168.1.3tcpssh-
    -
    ...
    -
    -
    -
    -
    -
    -
    DNATsamloc:192.168.1.3tcpssh-
    +
    DNATnetloc:192.168.1.5tcpwww-
    +
    ...
    +
    +
    +
    +
    +
    +
    -
    - -

    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.

    - + + +

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

    + +

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

    + +
    +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST

    +
    +
    +
    +
    +
    +
    +
    ...
    +
    +
    +
    +
    +
    +
    DNATsamfwtcpssh-
    +
    DNATnet!samloc:192.168.1.3tcpssh-
    +
    ...
    +
    +
    +
    +
    +
    +
    +
    + +

    The first rule allows Sam SSH access to the firewall. The second + rule says that any clients from the 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.

    +

    /etc/shorewall/rules

    - -

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

    - -

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

    - + +

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

    + +

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

    +

    Entries in the file have the following columns:

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

      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: +
        -
      • 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.
        -
        • - +
      • 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). +
        • -
      • 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 -a particular IP address (see Example 2 below for another usage). -That IP address is specified in the ORIGINAL DEST column.
        -
        - The IP address may be optionally -followed by ":" and a second IP address. This latter address, -if present, is used as the source address for packets forwarded -to the server (This is called "Source NAT" or SNAT).
        -
        - 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.
        • - +
      • 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 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 + a particular IP address (see Example 2 below for another usage). + That IP address is specified in the ORIGINAL DEST column.
      +
      + The IP address may be optionally + followed by ":" and a second IP address. This latter address, + if present, is used as the source address for packets +forwarded to the server (This is called "Source NAT" or SNAT).
      +
      + 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.

    - + name="PortForward"> Example 1.     You wish to forward all + ssh connection requests from the internet to local +system 192.168.1.3.

    +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    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.

    - + + +

    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.

    +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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.

    - + + +

    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.

    +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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 - - .

    - + + +

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

    +
    + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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:

    - -
    +
    + +

    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:

    + +

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

    - -

    Example 5. You wish to allow unlimited - DMZ access to the host with MAC address - 02:00:08:E3:FA:55.

    - + + +

    If you are running pure-ftpd, you would include "-p 65500:65534" on + 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.

    + +

    Example 5. You wish to allow unlimited + DMZ access to the host with MAC address + 02:00:08:E3:FA:55.

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

    Look here for information on other services. -

    - +
    + Using "DNAT-" rather than "DNAT" avoids two +extra copies of the third rule from being generated.
    + +

    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.

    - -

    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.

    - + +

    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.

    + +

    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.

    +

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

    - + +

    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 .

    +

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

    - -
    + +

    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:

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

    - -
    +
    + +

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

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

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

    - -
    - - + - - - - - - - - - - - + + + + + + + + + + +
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24206.124.146.176
    INTERFACE SUBNETADDRESS
    ipsec0:10.1.0.0/16192.168.9.0/24
    +
    -
    - -

    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.

    - -
    +
    + +

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

    + +
    - - - - - - - - - - - - - + + + + + + + + + + + + +
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24206.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 + +

    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.

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

    + +

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

    - +

    The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is - typically used for enabling -Proxy ARP on a small set -of systems since -you need one -entry in this file for each - system using proxy ARP. Columns - are:

    - + href="ProxyARP.htm">Proxy ARP. The file is + typically used for +enabling Proxy ARP on a +small set of systems +since you need +one entry in this file for each + system using proxy ARP. Columns + are:

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

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

    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.

    - -

    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:

    - + +

    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:

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

    - -
    + +

    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:

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

    - -

    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 +

    + +

    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.

    + +

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

    - + +

    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

    - -

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

    - + +

    + /etc/shorewall/nat

    + +

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

    +

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

    - + color="#ff0000"> 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.

    +

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

    - -

    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.

    - + +

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

    + +

    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.

    +

    /etc/shorewall/shorewall.conf

    - +

    This file is used to set the following firewall parameters:

    - +
      -
    • LOGMARKER - Added -at version 1.4.2
      -The value of this variable determines the leading part of the --log-prefix -("man iptables") used by Shorewall. Set this to "fp=" if you want to integrate -Shorewall with fireparse (http://www.fireparse.com). -Note that fireparse is unable to report on packets reported via ULOG. If -this variable is not supplied or is given the null value ("LOGMARKER=") then -"Shorewall:" is used.
      -
      • -
    • 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 'norfc1918' - mechanism are logged. The value must be a valid syslog level and if no level is given, - then info is assumed. Prior to Shorewall version 1.3.12, these -packets are always logged at the info level.
      • -
    • TCP_FLAGS_DISPOSITION - Added in Version - 1.3.11
      - Determines the disposition of TCP packets that fail - the checks enabled by the tcpflags - interface option and must have a value of ACCEPT (accept the -packet), REJECT (send an RST response) or DROP (ignore the packet). -If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") -then TCP_FLAGS_DISPOSITION=DROP is assumed.
      • -
    • TCP_FLAGS_LOG_LEVEL - Added in -Version 1.3.11
      - Determines the syslog level for logging packets - that fail the checks enabled by the tcpflags - interface option.The value must be a valid syslogd log level. -If you don't want to log these packets, set to the empty value -(e.g., TCP_FLAGS_LOG_LEVEL="").
      -
      • -
    • MACLIST_DISPOSITION - Added in -Version 1.3.10
      - Determines the disposition of connections -requests that fail MAC Verification - and must have the value ACCEPT (accept the connection request anyway), - REJECT (reject the connection request) or DROP (ignore the connection - request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") - then MACLIST_DISPOSITION=REJECT is assumed.
      • -
    • MACLIST_LOG_LEVEL - Added in -Version 1.3.10
      - Determines the 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.
      • -
    • 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:
      - +
    • 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 'norfc1918' mechanism + are logged. The value must be a valid syslog level and if no level is given, + then info is assumed. Prior to Shorewall version 1.3.12, these + packets are always logged at the info level.
      • +
    • TCP_FLAGS_DISPOSITION - Added +in Version 1.3.11
      + Determines the disposition of TCP packets that + fail the checks enabled by the tcpflags + interface option and must have a value of ACCEPT (accept the + packet), REJECT (send an RST response) or DROP (ignore the packet). + If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") + then TCP_FLAGS_DISPOSITION=DROP is assumed.
      • +
    • TCP_FLAGS_LOG_LEVEL - Added + in Version 1.3.11
      + Determines the syslog level for logging packets + that fail the checks enabled by the tcpflags + interface option.The value must be a valid syslogd log level. + If you don't want to log these packets, set to the empty value + (e.g., TCP_FLAGS_LOG_LEVEL="").
      +
      • +
    • MACLIST_DISPOSITION - Added + in Version 1.3.10
      + Determines the disposition of connections + requests that fail MAC Verification + and must have the value ACCEPT (accept the connection request anyway), + REJECT (reject the connection request) or DROP (ignore the connection + request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") + then MACLIST_DISPOSITION=REJECT is assumed.
      • +
    • MACLIST_LOG_LEVEL - Added + in Version 1.3.10
      + Determines the 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.
      • +
    • 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:
      +
        -
      • 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 + +

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

    /etc/shorewall/modules Configuration

    - -

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

    - -

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

    - + +

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

    + +

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

    +

    The loadmodule function is called as follows:

    - -
    -

    loadmodule <modulename> [ - <module parameters> ]

    -
    - + +
    +

    loadmodule <modulename> [ + <module parameters> ]

    +
    +

    where

    - -
    + +

    <modulename>

    - -
    -

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

    -
    - + +
    +

    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:

    - -
    -

    insmod moduledirectory/<modulename>.o <module - 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:

    - -
    -

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

    -
    - +
    +
    + +

    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:

    + +
    +

    insmod moduledirectory/<modulename>.o <module + 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:

    + +
    +

    insmod moduledirectory/<modulename>.o.gz <module + 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 .

    - + +

    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 .

    +

    Entries in the file have the following columns:

    - +
      -
    • SOURCE -- The source - zone. May be qualified by following the zone name -with a colon (":") and either an IP address, an IP subnet, - a MAC address in Shorewall Format or the +
    • 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:
      • - + href="#FW">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)

    -
    -
    - -

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

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

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

    - +
    + +

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

    +

    /etc/shorewall/blacklist

    - -

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

    - + +

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

    + 
          130.252.100.69
          206.124.146.0/24
    - -

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

    - + +

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

    +

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

    - +

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

    Shorewall also has a dynamic blacklist - capability.

    - -

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

    - + +

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

    - + +

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

    - -
    + +

    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.

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

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

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

    Updated 5/18/2003 - Tom Eastep -

    - +
    + +

    Updated 5/27/2003 - Tom Eastep +

    +

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

    diff --git a/Shorewall-docs/FAQ.htm b/Shorewall-docs/FAQ.htm index a23d7a211..a2fb782f3 100644 --- a/Shorewall-docs/FAQ.htm +++ b/Shorewall-docs/FAQ.htm @@ -1,1296 +1,1303 @@ - + - + - + - + Shorewall FAQ - + - + - - - + + - - - + + + +
    +

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

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

    - +
    +
    +
    + +
    +

    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.
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATnetloc:<local - IP address>[:<local port>]<protocol><port - #>
    -
    -
    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.
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATnetloc:192.168.1.5udp7777
    -
    -
    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.
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
    DNATnetloc:<local - IP address>[:<local port>]<protocol><port - #>-<external - IP>
    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:

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

    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.

    - -

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

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

    - -

    Otherwise:
    -

    - +

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

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

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

    and make your DNAT rule:

    -
    - -
    -
    + +

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

    + +

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

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

    + +

    Otherwise:
    +

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

    - -
    -

    Using this technique, you will want to configure your DHCP/PPPoE - client to automatically restart Shorewall each + +

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

    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:

    - +
    + +

    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 + b) Masquerade Z to itself.
    -
    - Example:

    - +
    + Example:

    +

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

    - + Interface: eth2
    + Subnet: 192.168.2.0/24

    +

    In /etc/shorewall/interfaces:

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

    In /etc/shorewall/policy:

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

    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?

    + +

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

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

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

    + +

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

    + +
    +

    http://www.shorewall.net/pub/shorewall/parsefw/
    + http://www.fireparse.com
    + http://cert.uni-stuttgart.de/projects/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:
    + +
    	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?

    + +
    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:
    + +
      +
    1. They are late-arriving replies to DNS queries.
      2. +
    2. They are corrupted reply packets.
      3. + +
    + 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 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
    + +
      +
    • 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:

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

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

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

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

    + +

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

    + +

    11. What Features does it have?

    + +

    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 +

    + +

    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:

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

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

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

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

    + +

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

    + +
    + + + + + - - - - - -
    SUBNET
    +     		TARGET
    +
    eth2192.168.2.0/24
    -
    -
    - -

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

    - -
    -
         LOGLIMIT=""
         LOGBURST=""
    - Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages - to a separate file.
    -
    - -

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

    - -

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

    - -
    -

    http://www.shorewall.net/pub/shorewall/parsefw/
    - http://www.fireparse.com
    - http://cert.uni-stuttgart.de/projects/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:
    - -
    	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?

    - -
    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:
    - -
      -
    1. They are late-arriving replies to DNS queries.
      2. -
    2. They are corrupted reply packets.
      3. - -
    - 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 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
    - -
      -
    • 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:

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

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

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

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

    - -

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

    - -

    11. What Features does it have?

    - -

    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 -

    - -

    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:

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

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

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

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

    - -

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

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

    4. + +

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

      +
      5. +
    5. + +

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

      +
      6. +
    6. + +

      The DNS settings on the local systems are wrong or the + user is running a DNS server on the firewall + and hasn't enabled UDP and TCP port 53 from the firewall to the internet.

      -
      7. - + +
    - -

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

    - -

    Answer: "man dmesg" -- add a suitable 'dmesg' command - to your startup scripts or place it in /etc/shorewall/start. - Under RedHat, the max log level that is sent to - the console is specified in /etc/sysconfig/init in the - LOGLEVEL variable.
    -

    - -

    17. How do I find out why this 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: "man dmesg" -- add a suitable 'dmesg' command + to your startup scripts or place it in /etc/shorewall/start. + Under RedHat, the max log level that is sent +to the console is specified in /etc/sysconfig/init in +the LOGLEVEL variable.
    +

    + +

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

    + Answer: Logging + occurs out of a number of chains (as indicated in the + log message) in Shorewall:
    +
      -
    1. man1918 - The - destination address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see man1918 - The + destination address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
      2. -
    2. rfc1918 -- The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see rfc1918 +- The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
      3. -
    3. all2<zone>, - <zone>2all or all2all - - You have a policy that specifies - a log level and this packet is being logged under that policy. - If you intend to ACCEPT this traffic then you need a rule to that effect.
      -
      4. -
    4. <zone1>2<zone2> - - Either you have a policy for <zone1> - to <zone2> that specifies a log level and - this packet is being logged under that policy or this packet - matches a rule that includes - a log level.
      5. -
    5. <interface>_mac - - The packet is being logged under the maclist - interface option.
      -
      6. -
    6. logpkt - -The packet is being logged under the logunclean - interface option.
      7. -
    7. badpkt - -The packet is being logged under the dropunclean - interface option -as specified in the LOGUNCLEAN setting in all2<zone>, + <zone>2all or all2all + - You have a policy +that specifies a log level and this packet is being +logged under that policy. If you intend to ACCEPT this +traffic then you need a rule to +that effect.
      +
      8. +
    8. <zone1>2<zone2> + - Either you have a policy for <zone1> + to <zone2> that specifies a log level and + this packet is being logged under that policy or this packet + matches a rule that +includes a log level.
      9. +
    9. <interface>_mac + - The packet is being logged under the maclist + interface option.
      +
      10. +
    10. logpkt +- The packet is being logged under the logunclean + interface option.
      11. +
    11. badpkt - + The packet is being logged under the dropunclean + interface option + as specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
      12. -
    12. blacklst -- The packet is being logged because the source IP -is blacklisted in the /etc/shorewall/blacklist - file.
      13. -
    13. newnotsyn - - The packet is being logged because it is a TCP packet - that is not part of any current connection yet it is not a -syn packet. Options affecting the logging of such packets include - NEWNOTSYN and LOGNEWNOTSYN in +
    14. blacklst + - The packet is being logged because the source IP + is blacklisted in the /etc/shorewall/blacklist + file.
      15. +
    15. newnotsyn - + The packet is being logged because it is a TCP packet + that is not part of any current connection yet it is not a +syn packet. Options affecting the logging of such packets include + NEWNOTSYN and LOGNEWNOTSYN in /etc/shorewall/shorewall.conf.
      16. -
    16. INPUT or - FORWARD - The packet has a source IP address - that isn't in any of your defined zones ("shorewall check" - and look at the printed zone definitions) or the chain is FORWARD +
    17. 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.
      18. -
    18. logflags - The packet - is being logged because it failed the checks implemented +
    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
    +
    + 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.

    - 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.
    - + 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
    -
    - Last updated 4/14/2003 - Tom Eastep + +

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

    + At the shell prompt, type:
    +
    + /sbin/shorewall version
    +
    + Last updated 4/14/2003 - Tom Eastep

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

    +

    +



    diff --git a/Shorewall-docs/Install.htm b/Shorewall-docs/Install.htm index beaa34d49..38a25882d 100644 --- a/Shorewall-docs/Install.htm +++ b/Shorewall-docs/Install.htm @@ -1,219 +1,220 @@ - + Shorewall Installation - + - + - + - - - - - - + + + + + +
    -

    Shorewall Installation and - Upgrade

    -
    +

    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 -(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.0-1 +
    • 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>.

      -
      - 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 - and install script:

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

    - -
      -
    • 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>).
      -
      - 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 upgrade of Shorewall to fail with the diagnostic:
      -
      -      error: failed dependencies:iproute is needed by shorewall-1.4.0-1 + 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 -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 -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"
      • +
    - -

    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.

    - + +

    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 the - directory name as in "shorewall-3.0.1").
      • -
    • If you are using 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 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 - or /etc/init.d then type "./install.sh"
      • -
    • For other distributions, determine where your -distribution installs init scripts and 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 + 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"
      • - +
    • 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.
      • +
    - 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 - QuickStart Guides contain all of the information you need.

    - + +

    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.

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

    Updated 4/8/2003 - Tom Eastep -

    - + +

    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 +the directory name as in "shorewall-3.0.1").
      • +
    • 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 + 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"
      • + +
    + 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 + QuickStart Guides contain all of the information you need.

    + +
      + +
    + +

    Updated 4/8/2003 - Tom Eastep +

    +

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

    +

    +
    diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index 43bd19380..c5b0ac99b 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -4,7 +4,7 @@ - + Shorewall News @@ -13,200 +13,255 @@ - + + - + - + - - - + + - + + - - + + +
    +
    - +

    Shorewall News Archive

    -
    - + +

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

    + 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. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) - by setting LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. Note: You may - not use ULOG with fireparse unless you modify fireparse.
      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. (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
      5. +
    5. 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.
      6. + +
    + +

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

    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

    - + @@ -225,2916 +280,2964 @@ affected all (zone,interface,address) tuples associated with the given - -

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

    - + +

    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. - +
    2. 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.
      3. +
    - 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:
    - + 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.
    -
    - + 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. - +
    4. 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.
      5. +
    5. Beginning with Shorewall 1.4.1, Shorewall will never create + rules to handle traffic from a group to itself.
      6. +
    6. A NONE policy is introduced in 1.4.1. When a policy of +NONE is specified from Z1 to Z2:
      7. +
    - +
      -
    • 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.
      • - +
    • 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. + 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:
    - + 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
      • - -
    - -

    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. -
    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. 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.
      +
      +
      5. +
    5. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
      +
      +
      6. +
    6. 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.
      +
      +
      7. +
    7. 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.
      +
      +
      8. +
    8. The Shorewall 1.2 syntax for DNAT and REDIRECT +rules is no longer accepted.
      +
      +
      9. +
    9. The ALLOWRELATED variable in shorewall.conf is +no longer supported. Shorewall 1.4 behavior is the same as 1.3 with + ALLOWRELATED=Yes.

      10. -
    10. Support for VLAN devices with names of the form -$DEV.$VID (e.g., eth0.0)
      -
      -
      11. -
    11. 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.
      -
      +
    12. The icmp.def file has been removed.
      13. -
    13. 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
      -
      14. - -
    - -


    - 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

    + + Changes for 1.4 include:
    -

    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
    -

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

    2/8/2003 - Shoreawall 1.3.14

    -

    The Beta includes the following changes:
    -

    +

    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.
      +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. 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. 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.
      -   
      + 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:
      -   
      +  
      + 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?
      -  
      +  
      +    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
      -
      8. +
    +


    + 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

    + +

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

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

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

    - + href="http://www.rettc.com">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. - +
    5. 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,....
      +
      +
      6. +
    6. The 'shorewall check' command now +prints out the applicable policy between each pair of zones.
      +
      +
      7. +
    7. 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.
      +
      +
      8. +
    8. 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.
      +
      9. +
    - -

    1/6/2003 - BURNOUT -

    - -

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

    - + +

    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 to a separate log file.
      6. -
    6. If you are running a kernel that has - a FORWARD chain in the mangle table ("shorewall show mangle" - will show you the chains in the mangle table), you can set -MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. -This allows for marking input packets based on their destination -even when you are using Masquerading or SNAT.
      7. -
    7. I have cluttered up the /etc/shorewall - directory with empty 'init', 'start', 'stop' and 'stopped' - files. If you already have a file with one of these names, don't - worry -- the upgrade process won't overwrite your file.
      8. -
    8. I have added a new RFC1918_LOG_LEVEL - variable to shorewall.conf. - This variable specifies the syslog level at which packets -are logged as a result of entries in the /etc/shorewall/rfc1918 -file. Previously, these packets were always logged at the 'info' -level.
      -
      9. - -
    - -

    12/20/2002 - Shorewall 1.3.12 Beta 3
    -

    - This version corrects a problem with Blacklist - logging. In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything - but ULOG, the firewall would fail to start and "shorewall refresh" - would also fail.
    - -

    12/20/2002 - Shorewall 1.3.12 Beta 2

    - -

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

    - Features include:
    +

    1. "shorewall refresh" now reloads - the traffic shaping rules (tcrules and tcstart).
      2. + the traffic shaping rules (tcrules and tcstart).
    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. + turns off debugging after an error occurs. This places +the point of the failure near the end of the trace rather +than up in the middle of it.
    3. "shorewall [re]start" has been -speeded up by more than 40% with my configuration. Your milage -may vary.
      4. +speeded up by more than 40% with my configuration. Your milage +may vary.
    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. +command has been added which shows the current packet classification + filters. The output from this command is also added as +a separate page in "shorewall monitor"
    5. ULOG (must be all caps) is now -accepted as a valid syslog level and causes the subject packets -to be logged using the ULOG target rather than the LOG target. - This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) - and log all Shorewall messages http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
    6. If you are running a kernel that - has a FORWARD chain in the mangle table ("shorewall show -mangle" will show you the chains in the mangle table), you can -set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for - marking input packets based on their destination even when you -are using Masquerading or SNAT.
      7. + has a FORWARD chain in the mangle table ("shorewall show + mangle" will show you the chains in the mangle table), you + can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for +marking input packets based on their destination even when you + are using Masquerading or SNAT.
    7. I have cluttered up the /etc/shorewall - directory with empty 'init', 'start', 'stop' and 'stopped' - files. If you already have a file with one of these names, don't - worry -- the upgrade process won't overwrite your file.
      8. + directory with empty 'init', 'start', 'stop' and 'stopped' + files. If you already have a file with one of these names, +don't worry -- the upgrade process won't overwrite your file. +
    8. I have added a new RFC1918_LOG_LEVEL + variable to shorewall.conf. + This variable specifies the syslog level at which packets + are logged as a result of entries in the /etc/shorewall/rfc1918 + file. Previously, these packets were always logged at the 'info' + level.
      +
    - You may download the Beta from:
    +

    12/20/2002 - Shorewall 1.3.12 Beta 3
    +

    + This version corrects a problem with + Blacklist logging. In Beta 2, if BLACKLIST_LOG_LEVEL was +set to anything but ULOG, the firewall would fail to start and +"shorewall refresh" would also fail.
    + + +

    12/20/2002 - Shorewall 1.3.12 Beta 2

    + + +

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

    + Features include:
    + + +
      +
    1. "shorewall refresh" now reloads + the traffic shaping rules (tcrules and tcstart).
      2. +
    2. "shorewall debug [re]start" + now turns off debugging after an error occurs. This places + the point of the failure near the end of the trace rather than + up in the middle of it.
      3. +
    3. "shorewall [re]start" has +been speeded up by more than 40% with my configuration. Your +milage may vary.
      4. +
    4. A "shorewall show classifiers" + command has been added which shows the current packet +classification filters. The output from this command is also +added as a separate page in "shorewall monitor"
      5. +
    5. ULOG (must be all caps) is + now accepted as a valid syslog level and causes the subject + packets to be logged using the ULOG target rather than the +LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
      6. +
    6. If you are running a kernel + that has a FORWARD chain in the mangle table ("shorewall + show mangle" will show you the chains in the mangle table), + you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This + allows for marking input packets based on their destination even + when you are using Masquerading or SNAT.
      7. +
    7. I have cluttered up the /etc/shorewall + directory with empty 'init', 'start', 'stop' and 'stopped' + files. If you already have a file with one of these names, + don't worry -- the upgrade process won't overwrite your file.
      8. + + +
    + You may download the Beta from:
    + +
    http://www.shorewall.net/pub/shorewall/Beta
    - ftp://ftp.shorewall.net/pub/shorewall/Beta
    -
    - + + +

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

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

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

    + +

    Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. + I have installed 9.0 on one of my systems and I am +now in a position to support Shorewall users who run Mandrake + 9.0.

    - +

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

    +

    - +

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

    - +

    12/3/2002 - Shorewall 1.3.11a

    - -

    This is a bug-fix roll up which includes Roger Aich's fix for DNAT with - excluded subnets (e.g., "DNAT foo!bar ..."). Current -1.3.11 users who don't need rules of this type need not upgrade -to 1.3.11.

    + +

    This is a bug-fix roll up which includes Roger Aich's fix for DNAT with + excluded subnets (e.g., "DNAT foo!bar ..."). Current + 1.3.11 users who don't need rules of this type need not + upgrade to 1.3.11.

    - +

    11/24/2002 - Shorewall 1.3.11

    - +

    In this version:

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

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

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

    11/14/2002 - Shorewall Documentation in PDF Format

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

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

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

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

      - -
    - Hopefully these -problems are now corrected.
    + +

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

    - -

    9/18/2002 -  Debian 1.3.8 Packages Available
    -

    + +

    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:

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

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

    9/11/2002 - Debian 1.3.7c Packages Available

    - +

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

    - +

    9/2/2002 - Shorewall 1.3.7c

    - -

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

    + +

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

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

    + +

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

    - +

    8/13/2002 - Documentation in the CVS Repository

    - -

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

    + +

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

    - +

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

    - -

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

    + +

    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:

    - +
      -
    • Causes - the firewall script to remove the lock file if it is - killed.
      • -
    • Once -again allows lists in the second column of the - /etc/shorewall/hosts file.
      • -
    • Includes - the latest QuickStart - Guides.
      • +
    • Causes + the firewall script to remove the lock file if it + is killed.
      • +
    • Once + again allows lists in the second column of the + /etc/shorewall/hosts +file.
      • +
    • Includes + the latest QuickStart + Guides.
      • - +
    - +

    7/29/2002 - New Shorewall Setup Guide Available

    - +

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

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

    - +

    7/28/2002 - Shorewall 1.3.5 Debian Package Available

    - -

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

    - +

    7/27/2002 - Shorewall 1.3.5a Released

    - +

    This interim release restores correct handling of REDIRECT rules.

    - +

    7/26/2002 - Shorewall 1.3.5 Released

    - -

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

    + +

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

    - +

     In this version:

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

    7/16/2002 - New Mirror in Argentina

    - -

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

    + +

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

    - +

    7/16/2002 - Shorewall 1.3.4 Released

    - +

    In this version:

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

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    - +

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

    - +

    7/6/2002 - Shorewall 1.3.3 Released

    - +

    In this version:

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

    6/25/2002 - Samples Updated for 1.3.2

    - -

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

    + +

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

    - +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/19/2002 - Documentation Available in PDF Format

    - -

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

    + +

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

    - +

    6/16/2002 - Shorewall 1.3.2 Released

    - +

    In this version:

    - + - +

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

    - -

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

    + +

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

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

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

    + +

    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 The 1.3.0 samples configurations had several serious problems that prevented + DNS and SSH from working properly. These + problems have been corrected in the 1.3.1 samples.

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    5/29/2002 - Shorewall 1.3.0 Released

    - -

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

    + +

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

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

    5/23/2002 - Shorewall 1.3 RC1 Available

    - -

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

    + +

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

    - + - +

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    - -

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

    + +

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

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

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    - -

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

    + +

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

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

    5/4/2002 - Shorewall 1.2.13 is Available

    - +

    In this version:

    - + - +

    4/30/2002 - Shorewall Debian News

    - -

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

    + +

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

    - +

    4/20/2002 - Shorewall 1.2.12 is Available

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

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

    - + - +

    Thanks, Lorenzo!

    - +

    4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE

    - -

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

    + +

    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:

    - + - +

    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 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.
      • +
    • 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.
      • +
    • 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
      • -
    • RFC -1918 checking in the mangle table has been streamlined - to no longer require packet marking. RFC 1918 checking - in the filter table has been changed to require half as - many rules as previously.
      • -
    • A 'shorewall - check' command has been added that does a cursory - validation of the zones, interfaces, hosts, rules and - policy files.
      • +
    • UPnP + probes (UDP destination port 1900) are now silently + dropped in the common chain
      • +
    • RFC + 1918 checking in the mangle table has been streamlined + to no longer require packet marking. RFC 1918 checking + in the filter table has been changed to require half + as many rules as previously.
      • +
    • A + 'shorewall check' command has been added that does + a cursory validation of the zones, interfaces, hosts, + rules and policy files.
      • - +
    - +

    2/18/2002 - 1.2.6 Debian Package is Available

    - +

    See http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    2/8/2002 - Shorewall 1.2.6 Released

    - +

    In this version:

    - +
      -
    • $-variables - may now be used anywhere in the configuration files - except /etc/shorewall/zones.
      • -
    • The -interfaces and hosts files now have their contents - validated before any changes are made to the existing - Netfilter configuration. The appearance of a zone -name that isn't defined in /etc/shorewall/zones causes "shorewall - start" and "shorewall restart" to abort without changing - the Shorewall state. Unknown options in either file cause -a warning to be issued.
      • -
    • A problem - occurring when BLACKLIST_LOGLEVEL was not set has - been corrected.
      • +
    • $-variables + may now be used anywhere in the configuration files + except /etc/shorewall/zones.
      • +
    • The + interfaces and hosts files now have their contents + validated before any changes are made to the existing + Netfilter configuration. The appearance of a zone + name that isn't defined in /etc/shorewall/zones causes "shorewall + start" and "shorewall restart" to abort without changing + the Shorewall state. Unknown options in either file +cause a warning to be issued.
      • +
    • A + problem occurring when BLACKLIST_LOGLEVEL was not + set has been corrected.
      • - +
    - +

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    - +

    see http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    2/1/2002 - Shorewall 1.2.5 Released

    - -

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

    + +

    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.
      • -
    • 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.
      • +
    • A + "shorewall version" command has been added
      • +
    • The + default value of the STATEDIR variable in /etc/shorewall/shorewall.conf + has been changed to /var/lib/shorewall in + order to conform to the GNU/Linux File Hierarchy Standard, + Version 2.2.
      • - +
    - +

    1/28/2002 - Shorewall 1.2.4 Released

    - +
      -
    • The "fw" - zone may now be given a - different name.
      • -
    • You may - now place end-of-line comments (preceded by '#') in - any of the configuration files
      • -
    • There -is now protection against against two state changing - operations occuring concurrently. This is implemented - using the 'lockfile' utility if it is available - (lockfile is part of procmail); otherwise, a less robust - technique is used. The lockfile is created in the STATEDIR - defined in /etc/shorewall/shorewall.conf and has the -name "lock".
      • -
    • "shorewall - start" no longer fails if "detect" is specified - in /etc/shorewall/interfaces - for an interface with subnet mask 255.255.255.255.
      • +
    • The + "fw" zone may now be given + a different name.
      • +
    • You + may now place end-of-line comments (preceded by +'#') in any of the configuration files
      • +
    • There + is now protection against against two state changing + operations occuring concurrently. This is implemented + using the 'lockfile' utility if it is available + (lockfile is part of procmail); otherwise, a less robust + technique is used. The lockfile is created in the STATEDIR + defined in /etc/shorewall/shorewall.conf and has the + name "lock".
      • +
    • "shorewall + start" no longer fails if "detect" is specified + in /etc/shorewall/interfaces + for an interface with subnet mask 255.255.255.255.
      • - +
    - +

    1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    1/20/2002 - Corrected firewall script available 

    - -

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

    + +

    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:

    - + - +

    The following problems were corrected:

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

    1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release

    - -

    Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution - that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo - for details.

    + +

    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 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 logged and at what syslog level using the - BLACKLIST_LOGLEVEL - setting in /etc/shorewall/shorewall.conf
        • -
      • You -list the IP addresses/subnets that you wish to blacklist - in /etc/shorewall/blacklist
        • -
      • You -specify the interfaces you want checked against the - blacklist using the new "blacklist" option - in /etc/shorewall/interfaces.
        • -
      • The -black list is refreshed from /etc/shorewall/blacklist - by the "shorewall refresh" command.
        • +
      • You + specify whether you want packets from blacklisted + hosts dropped or rejected using the BLACKLIST_DISPOSITION + setting in /etc/shorewall/shorewall.conf
        • +
      • You + specify whether you want packets from blacklisted + hosts logged and at what syslog level using the + BLACKLIST_LOGLEVEL + setting in /etc/shorewall/shorewall.conf
        • +
      • You + list the IP addresses/subnets that you wish to blacklist + in /etc/shorewall/blacklist
        • +
      • You + specify the interfaces you want checked against + the blacklist using the new "blacklist" option + in /etc/shorewall/interfaces.
        • +
      • The + black list is refreshed from /etc/shorewall/blacklist + by the "shorewall refresh" command.
        • - +
      -
      • -
    • Use of - TCP RST replies has been expanded  +
      • +
    • Use + of TCP RST replies has been expanded  - + +
        -
      • TCP -connection requests rejected because of a REJECT policy - are now replied with a TCP RST packet.
        • -
      • TCP -connection requests rejected because of a protocol=all - rule in /etc/shorewall/rules are now replied - with a TCP RST packet.
        • +
      • TCP + connection requests rejected because of a REJECT + policy are now replied with a TCP RST packet.
        • +
      • TCP + connection requests rejected because of a protocol=all + rule in /etc/shorewall/rules are now replied + with a TCP RST packet.
        • - +
      -
      • -
    • A LOGFILE specification - has been added to /etc/shorewall/shorewall.conf. LOGFILE is -used to tell the /sbin/shorewall program where to look for -Shorewall messages.
      • + +
    • A + LOGFILE specification + has been added to /etc/shorewall/shorewall.conf. LOGFILE + is used to tell the /sbin/shorewall program where to look + for Shorewall messages.
      • - +
    - +

    1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates - to the previously-released samples. There are - two new rules added:

    + target="_blank">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.
      • +
    • 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 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 those of you who have installed one of the Beta RPMS, you will need + to use the "--oldpackage" option when upgrading + to 1.2.0:

    - -
    + +
    - +

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

    -
    +
    - -

    12/19/2001 - Thanks to Steve - Cowles, there is now a Shorewall mirror - in Texas. This web site is mirrored at http://www.infohiiway.com/shorewall - and the ftp site is at 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.
      • -
    • In the - three-interface configuration, it is now possible - to configure the internet services that are to be available - to servers in the DMZ. 
      • +
    • Ping + is now allowed between the zones.
      • +
    • In + the three-interface configuration, it is now possible + to configure the internet services that are to be +available to servers in the DMZ. 
      • - +
    - +

    11/20/2001 - The current version of Shorewall is 1.1.18. 

    - +

    In this version:

    - +
      -
    • The spelling - of ADD_IP_ALIASES has been corrected in the shorewall.conf - file
      • -
    • The logic - for deleting user-defined chains has been simplified - so that it avoids a bug in the LRP version of the 'cut' - utility.
      • -
    • The /var/lib/lrpkg/shorwall.conf - file has been corrected to properly display - the NAT entry in that file.
      • +
    • The + spelling of ADD_IP_ALIASES has been corrected in +the shorewall.conf file
      • +
    • The + logic for deleting user-defined chains has been simplified + so that it avoids a bug in the LRP version of the +'cut' utility.
      • +
    • The + /var/lib/lrpkg/shorwall.conf file has been corrected + to properly display the NAT entry in that file.
      • - +
    - -

    11/19/2001 - Thanks to Juraj - Ontkanin, there is now a Shorewall - mirror in the Slovak Republic. The website is - now mirrored at 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.
      • -
    • Two Interfaces - -- A masquerading firewall.
      • -
    • Three -Interfaces -- A masquerading firewall with DMZ.
      • +
    • One + Interface -- for a standalone system.
      • +
    • Two + Interfaces -- A masquerading firewall.
      • +
    • Three + Interfaces -- A masquerading firewall with DMZ.
      • - +
    - +

    Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 - . See the README file for instructions.

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

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

    + +

    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:
      - 1. Create - a New Directory
      - 2. Copy -to that directory any of your configuration files that - you want to change.
      - 3. Modify - the copied files as needed.
      - 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.
      • -
    • 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.
      • -
    • 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.
      • +
    • 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
      + 2. +Copy to that directory any of your configuration files + that you want to change.
      + 3. +Modify the copied files as needed.
      + 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.
      • +
    • 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.
      • +
    • 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.
      • -
    • The second - column in the hosts file may now contain a comma-separated - list.
      -
      - Example:
      -     sea    - eth0:130.252.100.0/24,206.191.149.0/24
      • -
    • Handling - of multi-zone interfaces has been improved. See the - documentation for the - /etc/shorewall/interfaces file.
      • +
    • Shell + variables can now be used to parameterize Shorewall + rules.
      • +
    • The + second column in the hosts file may now contain a + comma-separated list.
      +
      + Example:
      +     + sea    eth0:130.252.100.0/24,206.191.149.0/24
      • +
    • Handling + of multi-zone interfaces has been improved. See +the documentation for +the /etc/shorewall/interfaces file.
      • - +
    - -

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

    + +

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

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

    + +

    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.
      • -
    • The /etc/shorewall/start - file (if any) is now processed after all -temporary rules have been deleted. This change prevents - the accidental removal of rules added during - the processing of that file.
      • -
    • The "dhcp" - interface option is now applicable to firewall - interfaces used by a DHCP server running on the firewall.
      • -
    • The RPM - can now be built from the .tgz file using "rpm -tb" 
      • +
    • A + "shorewall refresh" command has been added to allow + for refreshing the rules associated with the broadcast + address on a dynamic interface. This command should + be used in place of "shorewall restart" when the internet + interface's IP address changes.
      • +
    • The + /etc/shorewall/start file (if any) is now processed + after all temporary rules have been deleted. + This change prevents the accidental removal of + rules added during the processing of that file.
      • +
    • The + "dhcp" interface option is now applicable to firewall + interfaces used by a DHCP server running on the firewall.
      • +
    • The + RPM can now be built from the .tgz file using "rpm + -tb" 
      • - +
    - -

    7/6/2001 - The current version of Shorewall is 1.1.10. In this version

    + +

    7/6/2001 - The current version of Shorewall is 1.1.10. In this +version

    - +
      -
    • Shorewall - now enables Ipv4 Packet Forwarding by default. Packet - forwarding may be disabled by specifying IP_FORWARD=Off - in /etc/shorewall/shorewall.conf. If you don't - want Shorewall to enable or disable packet forwarding, - add IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf - file.
      • -
    • The "shorewall - hits" command no longer lists extraneous service - names in its last report.
      • -
    • Erroneous - instructions in the comments at the head of the firewall - script have been corrected.
      • +
    • Shorewall + now enables Ipv4 Packet Forwarding by default. +Packet forwarding may be disabled by specifying IP_FORWARD=Off + in /etc/shorewall/shorewall.conf. If you don't + want Shorewall to enable or disable packet forwarding, + add IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf + file.
      • +
    • The + "shorewall hits" command no longer lists extraneous + service names in its last report.
      • +
    • Erroneous + instructions in the comments at the head of the + firewall script have been corrected.
      • - +
    - -

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

    + +

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

    - +
      -
    • The "tunnels" - file really is in the RPM now.
      • -
    • SNAT -can now be applied to port-forwarded connections.
      • -
    • A bug -which would cause firewall start failures in some dhcp - configurations has been fixed.
      • -
    • The firewall - script now issues a message if you have the name - of an interface in the second column in an entry in -/etc/shorewall/masq and that interface is not up.
      • -
    • You can - now configure Shorewall so that it doesn't require the NAT and/or - mangle netfilter modules.
      • -
    • Thanks - to Alex  Polishchuk, the "hits" command from seawall - is now in shorewall.
      • -
    • Support - for IPIP tunnels has been added.
      • +
    • The + "tunnels" file really is in the RPM now.
      • +
    • SNAT + can now be applied to port-forwarded connections.
      • +
    • A + bug which would cause firewall start failures in +some dhcp configurations has been fixed.
      • +
    • The + firewall script now issues a message if you have +the name of an interface in the second column in an + entry in /etc/shorewall/masq and that interface +is not up.
      • +
    • You + can now configure Shorewall so that it doesn't require the NAT and/or + mangle netfilter modules.
      • +
    • Thanks + to Alex  Polishchuk, the "hits" command from seawall + is now in shorewall.
      • +
    • Support + for IPIP tunnels has been added.
      • - +
    - -

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

    + +

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

    - + - +

    6/2/2001 - The current version of Shorewall is 1.1.7. In this version

    - +
      -
    • The TOS - rules are now deleted when the firewall is stopped.
      • -
    • The .rpm - will now install regardless of which version of iptables - is installed.
      • -
    • The .rpm - will now install without iproute2 being installed.
      • -
    • The documentation - has been cleaned up.
      • -
    • The sample - configuration files included in Shorewall have been - formatted to 80 columns for ease of editing on a VGA - console.
      • +
    • The + TOS rules are now deleted when the firewall is stopped.
      • +
    • The + .rpm will now install regardless of which version + of iptables is installed.
      • +
    • The + .rpm will now install without iproute2 being installed.
      • +
    • The + documentation has been cleaned up.
      • +
    • The + sample configuration files included in Shorewall + have been formatted to 80 columns for ease of editing +on a VGA console.
      • - +
    - -

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

    + +

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

    - +
      -
    • You may now rate-limit the - packet log.
      • -
    • Previous - versions of Shorewall have an implementation of Static - NAT which violates the principle of least surprise.  - NAT only occurs for packets arriving at (DNAT) or send - from (SNAT) the interface named in the INTERFACE column of - /etc/shorewall/nat. Beginning with version 1.1.6, NAT effective - regardless of which interface packets come from or are destined - to. To get compatibility with prior versions, I have added - a new "ALL "ALL INTERFACES"  - column to /etc/shorewall/nat. By placing "no" or "No" - in the new column, the NAT behavior of prior versions may - be retained. 
      • -
    • The treatment - of IPSEC Tunnels where the - remote gateway is a standalone system has been improved. - Previously, it was necessary to include an additional rule allowing - UDP port 500 traffic to pass through the tunnel. Shorewall -will now create this rule automatically when you place the name -of the remote peer's zone in a new GATEWAY ZONE column in /etc/shorewall/tunnels. 
      • +
    • You may now rate-limit the +packet log.
      • +
    • + Previous versions of Shorewall have an implementation + of Static NAT which violates the principle + of least surprise.  NAT only occurs for packets arriving + at (DNAT) or send from (SNAT) the interface named in the + INTERFACE column of /etc/shorewall/nat. Beginning with version + 1.1.6, NAT effective regardless of which interface + packets come from or are destined to. To get compatibility + with prior versions, I have added a new "ALL "ALL INTERFACES"  column to /etc/shorewall/nat. + By placing "no" or "No" in the new column, the NAT +behavior of prior versions may be retained. 
      • +
    • The + treatment of IPSEC Tunnels + where the remote gateway is a standalone system has been + improved. Previously, it was necessary to include an additional + rule allowing UDP port 500 traffic to pass through the tunnel. + Shorewall will now create this rule automatically when you +place the name of the remote peer's zone in a new GATEWAY ZONE +column in /etc/shorewall/tunnels. 
      • - +
    - -

    5/20/2001 - The current version of Shorewall is 1.1.5. In this version

    + +

    5/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.
      • -
    • Corrected - problem where if "shorewall start" aborted early - (due to kernel configuration errors for example), superfluous - 'sed' error messages were reported.
      • -
    • Corrected - rules generated for port redirection.
      • -
    • The order - in which iptables kernel modules are loaded has been - corrected (Thanks to Mark Pavlidis). 
      • +
    • + Accepting RELATED connections + is now optional.
      • +
    • Corrected + problem where if "shorewall start" aborted early + (due to kernel configuration errors for example), superfluous + 'sed' error messages were reported.
      • +
    • Corrected + rules generated for port redirection.
      • +
    • The + order in which iptables kernel modules are loaded + has been corrected (Thanks to Mark Pavlidis). 
      • - +
    - -

    4/28/2001 - The current version of Shorewall is 1.1.3. In this version

    + +

    4/28/2001 - The current version of Shorewall is 1.1.3. In this +version

    - +
      -
    • Correct - message issued when Proxy ARP address added (Thanks - to Jason Kirtland).
      • -
    • /tmp/shorewallpolicy-$$ - is now removed if there is an error while starting - the firewall.
      • -
    • /etc/shorewall/icmp.def - and /etc/shorewall/common.def are now used - to define the icmpdef and common chains unless overridden - by the presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
      • -
    • In the - .lrp, the file /var/lib/lrpkg/shorwall.conf has been - corrected. An extra space after "/etc/shorwall/policy" - has been removed and "/etc/shorwall/rules" has been added.
      • -
    • When -a sub-shell encounters a fatal error and has stopped - the firewall, it now kills the main shell so that - the main shell will not continue.
      • -
    • A problem - has been corrected where a sub-shell stopped the - firewall and main shell continued resulting in a perplexing - error message referring to "common.so" resulted.
      • -
    • Previously, - placing "-" in the PORT(S) column in /etc/shorewall/rules - resulted in an error message during start. This has - been corrected.
      • -
    • The first - line of "install.sh" has been corrected -- I had - inadvertently deleted the initial "#".
      • +
    • Correct + message issued when Proxy ARP address added (Thanks + to Jason Kirtland).
      • +
    • /tmp/shorewallpolicy-$$ + is now removed if there is an error while + starting the firewall.
      • +
    • /etc/shorewall/icmp.def + and /etc/shorewall/common.def are now used + to define the icmpdef and common chains unless overridden + by the presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
      • +
    • In + the .lrp, the file /var/lib/lrpkg/shorwall.conf has + been corrected. An extra space after "/etc/shorwall/policy" + has been removed and "/etc/shorwall/rules" has been + added.
      • +
    • When + a sub-shell encounters a fatal error and has stopped + the firewall, it now kills the main shell so that + the main shell will not continue.
      • +
    • A + problem has been corrected where a sub-shell stopped + the firewall and main shell continued resulting in + a perplexing error message referring to "common.so" + resulted.
      • +
    • Previously, + placing "-" in the PORT(S) column in /etc/shorewall/rules + resulted in an error message during start. This + has been corrected.
      • +
    • The + first line of "install.sh" has been corrected -- +I had inadvertently deleted the initial "#".
      • - +
    - -

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

    + +

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

    - +
      -
    • Port -redirection now works again.
      • -
    • The icmpdef - and common chains may - now be user-defined.
      • -
    • The firewall - no longer fails to start if "routefilter" is - specified for an interface that isn't started. A warning - message is now issued in this case.
      • -
    • The LRP - Version is renamed "shorwall" for 8,3 MSDOS file - system compatibility.
      • -
    • A couple - of LRP-specific problems were corrected.
      • +
    • Port + redirection now works again.
      • +
    • The + icmpdef and common chains may now be user-defined.
      • +
    • The + firewall no longer fails to start if "routefilter" + is specified for an interface that isn't started. + A warning message is now issued in this case.
      • +
    • The + LRP Version is renamed "shorwall" for 8,3 MSDOS +file system compatibility.
      • +
    • A + couple of LRP-specific problems were corrected.
      • - +
    - +

    4/8/2001 - Shorewall is now affiliated with the Leaf Project -

    +

    - +

    4/5/2001 - The current version of Shorewall is 1.1.1. In this version:

    - +
      -
    • The common - chain is traversed from INPUT, OUTPUT and FORWARD - before logging occurs
      • -
    • The source - has been cleaned up dramatically
      • -
    • DHCP -DISCOVER packets with RFC1918 source addresses no -longer generate log messages. Linux DHCP clients generate - such packets and it's annoying to see them logged. 
      • +
    • The + common chain is traversed from INPUT, OUTPUT and +FORWARD before logging occurs
      • +
    • The + source has been cleaned up dramatically
      • +
    • DHCP + DISCOVER packets with RFC1918 source addresses no + longer generate log messages. Linux DHCP clients generate + such packets and it's annoying to see them logged. 
      • - +
    - +

    3/25/2001 - The current version of Shorewall is 1.1.0. In this version:

    - +
      -
    • Log messages - now indicate the packet disposition.
      • -
    • Error -messages have been improved.
      • -
    • The ability - to define zones consisting of an enumerated set of - hosts and/or subnetworks has been added.
      • -
    • The zone-to-zone - chain matrix is now sparse so that only those chains - that contain meaningful rules are defined.
      • -
    • 240.0.0.0/4 - and 169.254.0.0/16 have been added to the source - subnetworks whose packets are dropped under the norfc1918 - interface option.
      • -
    • Exits -are now provided for executing an user-defined script - when a chain is defined, when the firewall is initialized, - when the firewall is started, when the firewall - is stopped and when the firewall is cleared.
      • -
    • The Linux - kernel's route filtering facility can now be specified - selectively on network interfaces.
      • +
    • Log + messages now indicate the packet disposition.
      • +
    • Error + messages have been improved.
      • +
    • The + ability to define zones consisting of an enumerated + set of hosts and/or subnetworks has been added.
      • +
    • The + zone-to-zone chain matrix is now sparse so that only + those chains that contain meaningful rules are + defined.
      • +
    • 240.0.0.0/4 + and 169.254.0.0/16 have been added to the source + subnetworks whose packets are dropped under the + norfc1918 interface option.
      • +
    • Exits + are now provided for executing an user-defined script + when a chain is defined, when the firewall is initialized, + when the firewall is started, when the firewall + is stopped and when the firewall is cleared.
      • +
    • The + Linux kernel's route filtering facility can now +be specified selectively on network interfaces.
      • - +
    - +

    3/19/2001 - The current version of Shorewall is 1.0.4. This version:

    - +
      -
    • Allows - user-defined zones. Shorewall now has only one pre-defined - zone (fw) with the remaining zones being defined - in the new configuration file /etc/shorewall/zones. - The /etc/shorewall/zones file released in this version - provides behavior that is compatible with Shorewall 1.0.3. 
      • -
    • Adds -the ability to specify logging in entries in the - /etc/shorewall/rules file.
      • -
    • Correct - handling of the icmp-def chain so that only ICMP packets - are sent through the chain.
      • -
    • Compresses - the output of "shorewall monitor" if awk is installed. - Allows the command to work if awk isn't installed (although - it's not pretty).
      • +
    • Allows + user-defined zones. Shorewall now has only one pre-defined + zone (fw) with the remaining zones being defined + in the new configuration file /etc/shorewall/zones. + The /etc/shorewall/zones file released in this version + provides behavior that is compatible with Shorewall 1.0.3. 
      • +
    • Adds + the ability to specify logging in entries in the + /etc/shorewall/rules file.
      • +
    • Correct + handling of the icmp-def chain so that only ICMP + packets are sent through the chain.
      • +
    • Compresses + the output of "shorewall monitor" if awk is +installed. Allows the command to work if awk isn't installed + (although it's not pretty).
      • - +
    - -

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

    + +

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

    3/8/2001 - The current version of Shorewall is 1.0.2. It supports an - additional "gw" (gateway) zone for tunnels - and it supports IPSEC tunnels with end-points on -the firewall. There is also a .lrp available now.

    + +

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

    + +

    Updated 5/27/2003 - Tom Eastep +

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    +

    +

    diff --git a/Shorewall-docs/errata.htm b/Shorewall-docs/errata.htm index dcabb59d5..e3046f3fe 100644 --- a/Shorewall-docs/errata.htm +++ b/Shorewall-docs/errata.htm @@ -1,274 +1,298 @@ - + Shorewall 1.4 Errata - + - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Shorewall Errata/Upgrade Issues

    -
    - +

    IMPORTANT

    - +
      -
    1. +

    2. If you use a Windows system to download - a corrected script, be sure to run the script through - + dos2unix after you have moved - it to your Linux system.

      -
      3. -
    3. + it to your Linux system.

      +
      4. +

    4. If you are installing Shorewall for the first time and plan to use the .tgz and install.sh script, you can untar the archive, replace the 'firewall' script in the untarred directory - with the one you downloaded below, and then run install.sh.

      -
      5. -
    5. + with the one you downloaded below, and then run install.sh.

      +
      6. +

    6. When the instructions say to install a corrected - firewall script in /usr/share/shorewall/firewall, you + firewall script in /usr/share/shorewall/firewall, you may rename the existing file before copying in the new file.

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

    - +

    - -

    1.4.2

    + +

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

    1.4.3

      -
    • 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 ablve.
      +
    • The LOGMARKER variable introduced in version 1.4.3 was intended to +allow integration of Shorewall with Fireparse (http://www.firewparse.com). +Unfortunately, LOGMARKER only solved part of the integration problem. I have +implimented a new LOGFORMAT variable which will replace LOGMARKER which has +completely solved this problem and is currently in production with fireparse +here at shorewall.net. The updated files may be found at ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/. +See the 0README.txt file for details.
    -

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

    1.4.1

    +

    1.4.2

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

    1.4.0

    +

    1.4.1a, 1.4.1 and 1.4.0

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

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

    1.4.0

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

    - -
    + iptables version 1.2.3 + +

    There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, -RedHat released this buggy iptables in RedHat 7.2. 

    - + prevent it from working with Shorewall. Regrettably, + RedHat released this buggy iptables in RedHat 7.2. 

    +

    I have built a - corrected 1.2.3 rpm which you can download here  and I + 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.

    - + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

    +

    Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can - download from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works - fine.

    - + I have installed this RPM on my firewall and it +works fine.

    +

    If you would like to patch iptables 1.2.3 yourself, - the patches are available for download. This patch - which corrects a problem with parsing of the --log-level -specification while this patch - corrects a problem in handling the  TOS target.

    - + corrects a problem in handling the  TOS target.

    +

    To install one of the above patches:

    - +
      -
    • cd iptables-1.2.3/extensions
      • -
    • patch -p0 < the-patch-file
      • - +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • +
    -
    - +
    +

    Problems with kernels >= 2.4.18 and RedHat iptables

    - -
    + +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 - may experience the following:

    - -
    + may experience the following:

    + + 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    -
    - +
    +

    The RedHat iptables RPM is compiled with debugging enabled but the user-space debugging code was not updated to reflect recent changes in the Netfilter 'mangle' table. You can correct the problem by - installing - this iptables RPM. If you are already running a 1.2.5 -version of iptables, you will need to specify the --oldpackage -option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    -
    - + this iptables RPM. If you are already running a 1.2.5 + version of iptables, you will need to specify the --oldpackage + option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    +
    +

    Problems installing/upgrading - RPM on SuSE

    - + RPM on SuSE +

    If you find that rpm complains about a conflict with kernel <= - 2.2 yet you have a 2.4 kernel installed, simply use the "--nodeps" - option to rpm.

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

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

    - + change to the syntax used to specify multiport match rules; as + a consequence, if you install iptables 1.2.7 you must +be running Shorewall 1.3.7a or later or:

    + - +

    Problems with RH Kernel 2.4.18-10 and NAT
    -

    - /etc/shorewall/nat entries of the following form will - result in Shorewall being unable to start:
    -
    - + + /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
    - -

    Last updated 5/11/2003 - Tom Eastep + 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 5/27/2003 - Tom Eastep

    - +

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

    -
    +

    diff --git a/Shorewall-docs/images/Legend.png b/Shorewall-docs/images/Legend.png new file mode 100755 index 000000000..8ae90a1ec Binary files /dev/null and b/Shorewall-docs/images/Legend.png differ diff --git a/Shorewall-docs/images/Thumbs.db b/Shorewall-docs/images/Thumbs.db index 0a8e7f6e2..041cd0e2f 100644 Binary files a/Shorewall-docs/images/Thumbs.db and b/Shorewall-docs/images/Thumbs.db differ diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm index 22580a69b..bc913d13d 100644 --- a/Shorewall-docs/seattlefirewall_index.htm +++ b/Shorewall-docs/seattlefirewall_index.htm @@ -2,107 +2,117 @@ - + Shoreline Firewall (Shorewall) 1.4 - + - + - - - - + + + - + + - - + +
    +
    + + +

    Shorwall Logo - (Shorewall Logo) -

    - + (Shorewall Logo) + + + - -
    + +
    - +

    Shorewall 1.4 "iptables made easy"
    -
    +
    -

    -
    + +
    - +

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

    What is it?

    - -

    The Shoreline Firewall, more commonly known as "Shorewall", is -a Netfilter (iptables) based -firewall that can be used on a dedicated firewall system, a multi-function - gateway/router/server or on a standalone GNU/Linux system.

    + + +

    The Shoreline Firewall, more commonly known as "Shorewall", is a + Netfilter (iptables) based firewall + that can be used on a dedicated firewall system, a multi-function + gateway/router/server or on a standalone GNU/Linux system.

    - -

    This program is free software; you can redistribute it and/or modify - it - under the terms of Version 2 of the -GNU General Public License as published by the Free Software - Foundation.
    -
    - This - program is distributed in the hope that - it will be useful, but WITHOUT ANY WARRANTY; - without even the implied warranty of MERCHANTABILITY - or FITNESS FOR A PARTICULAR PURPOSE. - See the GNU General Public License for more details.
    + +

    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.
    -
    - You - should have received a copy of the GNU - General Public License along with - this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, - MA 02139, USA

    +
    + + This program is distributed in the hope + that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty + of MERCHANTABILITY or FITNESS FOR A PARTICULAR + PURPOSE. See the GNU General Public License + for more details.
    + +
    + + You should have received a copy of the + GNU General Public License along + with this program; if not, write to the Free + Software Foundation, Inc., 675 Mass + Ave, Cambridge, MA 02139, USA

    - + +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -110,216 +120,288 @@ GNU General Public License as published by the Free Software - -

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

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

    News

    - -

    5/20/2003 - Shorewall-1.4.3a 5/27/2003 - Shorewall-1.4.4a (New) -
    -

    -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

    + 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 (New) -
    -

    -     Problems Corrected:
    +

    + 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. 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. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) - by setting LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. -Note: You may not use ULOG with fireparse unless you modify fireparse.
      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

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

    The list server will be down this morning for upgrade to RH9.0.
    -

    + + +

    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  

    -

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

    +

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

    - -

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

    + +

    4/26/2003 - lists.shorewall.net Downtime

    - -

    4/12/2002 - Greater Seattle Linux Users Group Presentation -

    + +

    The list server will be down this morning for upgrade to RH9.0.
    +

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

    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/12/2002 - Greater Seattle Linux Users Group Presentation +

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

    +

    - 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.
    - + action="http://lists.shorewall.net/cgi-bin/htsearch"> +
    + Note: +     Search is unavailable + Daily 0200-0330 GMT.
    + - +

    Quick Search
    -

    - +

    +
    - - + +

    Extended Search

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

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

    + +

    Updated 5/27/2003 - Tom Eastep +
    +

    +
    +
    diff --git a/Shorewall-docs/shorewall_firewall_structure.htm b/Shorewall-docs/shorewall_firewall_structure.htm index cf8c57a81..b27c3ee0b 100644 --- a/Shorewall-docs/shorewall_firewall_structure.htm +++ b/Shorewall-docs/shorewall_firewall_structure.htm @@ -1,175 +1,334 @@ + - - - - - -Shorewall Firewall Structure + + + + + + + + + Shorewall Firewall Structure - - - - - - - -
    -

    Firewall Structure

    -
    -

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

    -
      -
    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 since their servers -may have been compromised through a security exploit.
      3. -
    3. - 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.
      4. -
    -

    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.

    -

    While zones are normally disjoint (no two zones have a host in common), - there are cases where nested or overlapping zone definitions are appropriate.

    -

    For a general picture of how packets traverse a Netfilter firewall, see - - http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES.
    + + + + + + + + + +
    +

    Firewall Structure

    +
    + +

    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:

    + +
      +
    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 +since their servers may have been compromised through a security exploit.
      3. +
    3. 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.
      4. + +
    + +

    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.

    + +

    While zones are normally disjoint (no two zones have a host in common), + 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. + +
    + +

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

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

    + +
    (Box Legend)
    - 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  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 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 address doesn't match any of the rules in the - interface_in chain then the packet enters a chain called sourcezone_dnat +

    + +

    + +

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

    + +
    Netfilter Flow Diagram +
    + +


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

      -

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

      -

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

      -

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

      -

      - For each record in the /etc/shorewall/policy file, a chain is created. Policies -in that file are expressed in terms of a source zone and destination zone -where these zones may be a zone defined in /etc/shorewall/zones, "fw" or -"all". Policies specifying the pseudo-zone "all" matches all defined zones -and "fw". These chains are referred to as 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. -
      -

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

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

      - Just because connections of a particular type are allowed between zone A - and the firewall and are also allowed between the firewall and zone B - 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.

      -

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

      -

      Last modified 8/22/2002 - Tom -Eastep

      -Copyright © 2001, 2002 Thomas M. Eastep. \ No newline at end of file + 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.
      +
      +

      2. +
    2. 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.
      3. + +
        +
      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. + +
      +
    3. 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.
      4. + +
    + +

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

    + +

    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.

    + +

    For each record in the /etc/shorewall/policy file, a chain is created. + Policies in that file are expressed in terms of a source zone and destination + zone where these zones may be a zone defined in /etc/shorewall/zones, +"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined + zones and "fw". These chains are referred to as 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. + +
    + +

    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:

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

    Just because connections of a particular type are allowed between zone + A and the firewall and are also allowed between the firewall and zone +B 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.

    + +

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

    + +

    Last modified 5/22/2003 - Tom Eastep

    + +

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

    +
    +
    +
    + + diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index 5f6fd28dd..27258896c 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -2,335 +2,420 @@ - + Shoreline Firewall (Shorewall) 1.3 - + - + - - + - + + - + + + - - + +
    +
    +

    Shorwall Logo - Shorewall 1.4 - - "iptables made easy"
    - Shorewall 1.4 + - "iptables made +easy"
    +
    -     + -

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

    What is it?

    - -

    The Shoreline Firewall, more commonly known as "Shorewall", is - a Netfilter - (iptables) based firewall that can be used on - a dedicated firewall system, a multi-function gateway/router/server - or on a standalone GNU/Linux system.

    - - -

    This program is free software; you can redistribute it and/or modify - it - under the terms of Version 2 of the -GNU General Public License as published by the Free Software - Foundation.
    - -
    - -This program is distributed in the hope - that it will be useful, but WITHOUT ANY - WARRANTY; without even the implied warranty - of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License - for more details.
    - -
    - -You should have received a copy of the GNU - General Public License along with - this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, - MA 02139, USA

    - - - -

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    + +

    The Shoreline Firewall, more commonly known as "Shorewall", is + a Netfilter + (iptables) based firewall that can be used +on a dedicated firewall system, a multi-function + gateway/router/server or on a standalone GNU/Linux system.

    +

    This program is free software; you can redistribute it and/or modify + it + under the terms of Version 2 of the GNU +General Public License as published by the Free Software + Foundation.
    + +
    + + This program is distributed in the hope + that it will be useful, but WITHOUT ANY + WARRANTY; without even the implied warranty + of MERCHANTABILITY or FITNESS FOR A PARTICULAR + PURPOSE. See the GNU General Public License + for more details.
    + +
    + + You should have received a copy of the + GNU General Public License along + with this program; if not, write to the Free + Software Foundation, Inc., 675 Mass + Ave, Cambridge, MA 02139, USA

    + + + + +

    Copyright 2001, 2002, 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.
    - + 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.
    - + New to Shorewall? Start by selecting the QuickStart Guide that most closely + match your environment and follow the step by step instructions.
    + +

    News

    - + - -

    5/20/2003 - Shorewall-1.4.3a 5/27/2003 - Shorewall-1.4.4a (New) -
    -

    -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

    + 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 (New) -
    -

    -     Problems Corrected:
    -     +

    + 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. 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. - +
    3. 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.
      +
      +
      4. +
    4. 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.
      +
      +
      5. +
    5. 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.
      6. +
    -     New Features:
    -     + +

    5/20/2003 - Shorewall-1.4.3a +
    +

    + This version primarily corrects the documentation included in the .tgz + and in the .rpm. In addition:
    +
      -
    1.  IPV6-IPV4 (6to4) -tunnels are now supported in the /etc/shorewall/tunnels file.
      2. -
    2. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) by setting -LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. -Note: You may not use ULOG with fireparse unless you modify fireparse.
      3. - +
    3. (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
      4. +
    4. 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.
      +
      5. +
    - -

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

    + +

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

      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 -

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

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

    + +

    5/8/2003 - Shorewall Mirror in Chile  

    + + +

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

    -

    4/12/2002 - Greater Seattle Linux Users Group Presentation -

    +

    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 +

    + + +

    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 +

    + + +
    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.
    + target="_top">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.3.14 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

    -     		- + +
    - + action="http://lists.shorewall.net/cgi-bin/htsearch"> + +


    - Note:     - Search is unavailable Daily 0200-0330 - GMT.
    -  

    - - + Note: + Search is unavailable Daily 0200-0330 + GMT.
    +  

    + +

    Quick Search
    - - +

    - -
    - + + + +

    Extended Search

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

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

    + +

    Updated 5/27/2003 - Tom Eastep +
    +

    +
    +
    +
    diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm index a646d340e..368f20fa9 100644 --- a/Shorewall-docs/support.htm +++ b/Shorewall-docs/support.htm @@ -1,79 +1,81 @@ - + - + Shorewall Support Guide - + - - - + + - - - + + + + +
    - +
    +

    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.
      -
    • Shorewall versions earlier +
    • Shorewall versions earlier that 1.3.0 are no longer supported.
      -
      • -
    • More than half of the questions posted on the support -list have answers directly accessible from the Documentation - Index
      -
      • -
    • - The FAQ has solutions - to more than 20 common problems.
      • -
    • The - Troubleshooting - Information contains a number of tips to help +
      • +
    • More than half of the questions posted on the support + list have answers directly accessible from the Documentation + Index
      +
      • +
    • + The FAQ has +solutions to more than 20 common problems.
      • +
    • The + Troubleshooting + Information contains a number of tips to help you solve common problems.
      • -
    • The - Errata has links - to download updated components.
      • -
    • The Site - and Mailing List Archives search facility can locate documents - and posts about similar problems:
      • - +
    • The + Errata has links + to download updated components.
      • +
    • The Site + and Mailing List Archives search facility can locate documents + and posts about similar problems:
      • +
    - +

    Site and Mailing List Archive Search

    - -
    + +
    Match: - + action="http://lists.shorewall.net/cgi-bin/htsearch"> Match: + - Format: + Format: + - Sort by: + Sort by: + - Include Mailing List Archives: - + size="-1"> 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 exact kernel version you +are running
        +
        + uname +-a
        +
        +
        • +
      - +
        -
      • the complete, exact output of
        -
        - ip addr -show
        -
        -
        • - -
      - -
        -
      • the complete, exact output of
        -
        - ip route +
      • the complete, exact output of
        +
        + ip addr show
        -
        -
        • - +
        +         +
      - +
        -
      • If your kernel is modularized, -the exact output from
        -
        - lsmod
        -
        • - +
      • 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 +
      • 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 + 4. Post the /tmp/status.txt file as an attachment.
        +
        +
        • +
      • 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 +
    • 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.
      • - +
      + +
    • 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 + +
    The author gratefully acknowleges that the above list was + heavily plagiarized from the excellent LEAF document by 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 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.
    - + +

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

    Where to Send your Problem Report or to Ask for Help

    - -
    If you have a quick question about -capabilities or where to find something, you may use the Shorewall Support - Forum. DO NOT POST THE OUTPUT OF "shorewall status" TO THE FORUM; - I WON'T LOOK AT IT. If you need to supply "shorewall status" -output, use the appropriate mailing list below.
    - + +

    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 Shorewall users mailing - list. Do not expect to get free MNF support on the list.
    - + style="font-weight: 400;">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 Shorewall users mailing + list. Do not expect to get free MNF support on the list.
    +

    Otherwise, please post your question or problem to the Shorewall users mailing - list .

    - + href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing + list .

    +

    To Subscribe to the mailing list go to http://lists.shorewall.net/mailman/listinfo/shorewall-users - .
    -

    -
    - + href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users + .
    +

    +
    +

    For information on other Shorewall mailing lists, go to http://lists.shorewall.net
    -

    - -

    Last Updated 5/12/2003 - Tom Eastep

    - +

    + +

    Last Updated 5/19/2003 - Tom Eastep

    +

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

    diff --git a/Shorewall-docs/three-interface.htm b/Shorewall-docs/three-interface.htm index f5a621fb7..dd86feb72 100644 --- a/Shorewall-docs/three-interface.htm +++ b/Shorewall-docs/three-interface.htm @@ -1,1212 +1,1198 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    +

    Three-Interface Firewall

    -
    - +

    Version 2.0.1

    - -

    Setting up a Linux system as a firewall for a small network - with DMZ is a fairly straight-forward task if you understand the + +

    Setting up a Linux system as a firewall for a small network + with DMZ is a fairly straight-forward task if you understand the basics and follow the documentation.

    - -

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall + +

    This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall in one of its more popular configurations:

    - +
      -
    • Linux system used as a firewall/router for a small -local network.
      • -
    • Single public IP address.
      • -
    • DMZ connected to a separate ethernet interface.
      • -
    • Connection through DSL, Cable Modem, ISDN, Frame Relay, - dial-up, ...
      • - +
    • Linux system used as a firewall/router for a small + local network.
      • +
    • Single public IP address.
      • +
    • DMZ connected to a separate ethernet interface.
      • +
    • Connection through DSL, Cable Modem, ISDN, Frame +Relay, dial-up, ...
      • +
    - +

    Here is a schematic of a typical installation.

    - +

    -

    - -

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

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

    - +

    +

    -     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 +     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 +     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 + href="http://www.shorewall.net/pub/shorewall/Samples/">three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy + the files to /etc/shorewall (the files will replace files with the same names that were placed in /etc/shorewall when Shorewall was installed).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration + +

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

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the three-interface sample configuration, + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the three-interface sample configuration, the following zone names are used:

    - + - + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    NameDescription
    NameDescription
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    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, + +

    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.

    - +
      -
    • You express your default policy for connections from +
    • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
      • -
    • You define exceptions to those default policies in -the /etc/shorewall/rules file.
      • - +
    • You define exceptions to those default policies in + the /etc/shorewall/rules file.
      • +
    - -

    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 three-interface sample + +

    The /etc/shorewall/policy file included with the three-interface sample has the following policies:

    - -
    + +
    - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    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 +

    + +
    +

    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
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    fwnetACCEPT  
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network +
    2. allow all connection requests from your local network to the internet
      3. -
    3. drop (ignore) all connection requests from the internet +
    4. drop (ignore) all connection requests from the internet to your firewall or local network
      5. -
    5. optionally accept all connection requests from the -firewall to the internet (if you uncomment the additional policy)
      6. -
    6. reject all other connection requests.
      7. - +
    7. optionally accept all connection requests from the + firewall to the internet (if you uncomment the additional policy)
      8. +
    8. reject all other connection requests.
      9. +
    - +

    -     At this point, edit your /etc/shorewall/policy file +     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. +

    + +

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

    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 DMZ Interface will also be an ethernet adapter + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your + DMZ computers will be connected to the same switch (note: If you have + only a single DMZ system, you can connect the firewall directly to the + computer using a cross-over cable).

    +

    - Do not connect more than one interface to the same - hub or switch (even for testing). It won't work the way that you -expect it to and you will end up confused and believing that Shorewall -doesn't work at all.

    - +     Do not connect more than one interface to the same + hub or switch (even for testing). It won't work the way that you expect + it to and you will end up confused and believing that Shorewall doesn't + work at all.

    +

    -     The Shorewall three-interface sample configuration assumes - that the external interface is eth0, the local interface is - eth1 and the DMZ interface is eth2. If your configuration - is different, you will have to modify the sample /etc/shorewall/interfaces - file accordingly. While you are there, you may wish to review the -list of options that are specified for the interfaces. Some hints:

    - +     The Shorewall three-interface sample configuration assumes + that the external interface is eth0, the local interface is + eth1 and the DMZ interface is eth2. If your configuration + is different, you will have to modify the sample /etc/shorewall/interfaces + file accordingly. While you are there, you may wish to review the list + of options that are specified for the interfaces. Some hints:

    +
      -
    • -

      If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-". -

      -
      • -
    • -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from +

    • +

      If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-". +

      +
      • +
    • +

      If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the option list.

      -
      • - + +
    - +

    IP Addresses

    - -

    Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you - a single Public IP address. This address may be assigned via - the Dynamic Host Configuration Protocol (DHCP) or as part of -establishing your connection when you dial in (standard modem) or establish -your PPP connection. In rare cases, your ISP may assign you a static -IP address; that means that you configure your firewall's external interface - to use that address permanently. Regardless of how the address - is assigned, it will be shared by all of your systems when you access -the Internet. You will have to assign your own addresses for your internal -network (the local and DMZ Interfaces on your firewall plus your other computers). -RFC 1918 reserves several Private IP address ranges for this purpose:

    - -
    + +

    Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you + a single Public IP address. This address may be assigned via + the Dynamic Host Configuration Protocol (DHCP) or as part of +establishing your connection when you dial in (standard modem) or establish +your PPP connection. In rare cases, your ISP may assign you a static +IP address; that means that you configure your firewall's external interface + to use that address permanently. Regardless of how the address + is assigned, it will be shared by all of your systems when you access +the Internet. You will have to assign your own addresses for your internal +network (the local and DMZ Interfaces on your firewall plus your other computers). + RFC 1918 reserves several Private IP address ranges for this purpose:

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

    -     Before starting Shorewall, you should look at the -IP address of your external interface and if it is one of the above - ranges, you should remove the 'norfc1918' option from the external +     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 +

    + +
    +

    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.

    -
    - -
    + href="shorewall_setup_guide.htm#Subnets">Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive "1" bits from + the left of the subnet mask.

    +
    + +

    Example sub-network:

    -
    - -
    -
    +
    + +
    +
    - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    -
    - -
    -

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above +

    + + +
    +

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

    + +
    +

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

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

    - -

    The remainder of this quide will assume that you have configured + +

    The remainder of this quide will assume that you have configured your network as shown here:

    - +

    -

    - -

    The default gateway for the DMZ computers would be 10.10.11.254 +

    + +

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

    - -

    -     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 Address Translation (NAT). The firewall rewrites the -source address in the packet to be the address of the firewall's external -interface; in other words, the firewall makes it look as if the firewall - itself is initiating the connection.  This is necessary so that the - destination host will be able to route return packets back to the firewall - (remember that packets whose destination address is reserved by RFC -1918 can't be routed accross the internet). When the firewall receives -a return packet, it rewrites the destination address back to 10.10.10.1 - and forwards the packet on to local computer 1.

    - -

    On Linux systems, the above process is often referred to -as IP Masquerading and you will also see the term Source Network -Address Translation (SNAT) used. Shorewall follows the convention used -with Netfilter:

    - -
      -
    • -

      Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

      -
      • -
    • -

      SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local - network to use.

      -
      • - -
    - -

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

    - -

    -     If your external firewall interface is eth0, your - local interface eth1 and your DMZ interface is eth2 -then you do not need to modify the file provided with the sample. Otherwise, - edit /etc/shorewall/masq and change it to match your configuration.

    - -

    -     If your external 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, +     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 +Address Translation (NAT). The firewall rewrites the source address +in the packet to be the address of the firewall's external interface; +in other words, the firewall makes it look as if the firewall itself +is initiating the connection.  This is necessary so that the destination +host will be able to route return packets back to the firewall (remember +that packets whose destination address is reserved by RFC 1918 can't + be routed accross the internet). When the firewall receives a return +packet, it rewrites the destination address back to 10.10.10.1 and forwards +the packet on to local computer 1.

    + +

    On Linux systems, the above process is often referred to as + IP Masquerading and you will also see the term Source Network Address + Translation (SNAT) used. Shorewall follows the convention used with + Netfilter:

    + +
      +
    • +

      Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

      +
      • +
    • +

      SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local + network to use.

      +
      • + +
    + +

    In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file.

    + +

    +     If your external firewall interface is eth0, +your local interface eth1 and your DMZ interface is eth2 +then you do not need to modify the file provided with the sample. Otherwise, + edit /etc/shorewall/masq and change it to match your configuration.

    + +

    +     If your external 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:
    -

    - +

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

    Port Forwarding (DNAT)

    - -

    One of your goals will be to run one or more servers on your - DMZ computers. Because these computers have RFC-1918 addresses, it - is not possible for clients on the internet to connect directly to -them. It is rather necessary for those clients to address their connection - requests to your firewall who rewrites the destination address to the - address of your server and forwards the packet to that server. When -your server responds, the firewall automatically performs SNAT to -rewrite the source address in the response.

    - -

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure -port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - -

    The general form of a simple port forwarding rule in /etc/shorewall/rules + +

    One of your goals will be to run one or more servers on your + DMZ computers. Because these computers have RFC-1918 addresses, it + is not possible for clients on the internet to connect directly to +them. It is rather necessary for those clients to address their connection + requests to your firewall who rewrites the destination address to the + address of your server and forwards the packet to that server. When your + server responds, the firewall automatically performs SNAT to rewrite + the source address in the response.

    + +

    The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure + port forwarding using DNAT rules in the /etc/shorewall/rules file.

    + +

    The general form of a simple port forwarding rule in /etc/shorewall/rules is:

    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - + + - - - - - - - + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server + DNATnetdmz:<server local ip address> [:<server port>]<protocol><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 +

    + +

    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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
    ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
    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).
      • - +
    • 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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000  
    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 +

    + +

    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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    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 +

    + +

    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. - +
    3. Include the following in /etc/shorewall/params:
      +
      + ETH0_IP=`find_interface_address eth0`
      +  
      4. +
    4. Make your loc->dmz rule:
      5. +
    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    -     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    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.

    - +
    + +

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

    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 your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers + or if those addresses are available on their web site, you can configure + your internal systems to use those addresses. If that information + isn't available, look in /etc/resolv.conf on your firewall system + -- the name servers are given in "nameserver" records in that file.

      -
      • -
    • +
      • +

    • -     You can configure a Caching Name Server on your - firewall or in your DMZ. Red Hat has an RPM for a caching -name server (which also requires the 'bind' RPM) and for Bering -users, there is dnscache.lrp. If you take this approach, you configure -your internal systems to use the caching name server as their primary -(and only) name server. You use the internal IP address of the firewall -(10.10.10.254 in the example above) for the name server address if -you choose to run the name server on your firewall. To allow your local -systems to talk to your caching name server, you must open port 53 -(both UDP and TCP) from the local network to the server; you do that -by adding the rules in /etc/shorewall/rules.

      -
      • - +     You can configure a Caching Name Server on your + firewall or in your DMZ. Red Hat has an RPM for a caching +name server (which also requires the 'bind' RPM) and for Bering users, + there is dnscache.lrp. If you take this approach, you configure your + internal systems to use the caching name server as their primary (and + only) name server. You use the internal IP address of the firewall (10.10.10.254 + in the example above) for the name server address if you choose to + run the name server on your firewall. To allow your local systems to +talk to your caching name server, you must open port 53 (both UDP +and TCP) from the local network to the server; you do that by adding +the rules in /etc/shorewall/rules.

      + +
    - -
    -

    If you run the name server on the firewall: + +

    +

    If you run the name server on the firewall: - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    -

    -
    - -
    -
    +

    +
    + +
    +

    Run name server on DMZ computer 1

    - + - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    -
    -
    - -
    +
    + + +

    Other Connections

    -
    - -
    +
    + +

    The three-interface sample includes the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    -
    -
    - -
    -

    Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy + +

    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy allowing all connections from the firewall to the internet.

    -
    - -
    +
    + +

    The sample also includes:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    -
    -
    - -
    -

    That rule allows you to run an SSH server on your firewall - and in each of your DMZ systems and to connect to those servers + +

    + +
    +

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

    + +
    +

    If you wish to enable other connections between your systems, the general format is:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    -
    -
    - -
    -

    Example - You want to run a publicly-available DNS server + +

    + +
    +

    Example - You want to run a publicly-available DNS server on your firewall system:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwudp
    +     		53#Allow DNS accessfrom the internet
    -
    -
    - -
    -

    Those two rules would of course be in addition to the rules + +

    + +
    +

    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:

    -
    - -
    -
    +
    + +
    +

    If you don't know what port and protocol a particular application + uses, look here.

    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you + want shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    + +
    + +

    - +

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible +     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 modify /etc/shorewall/rules to add or remove other - connections as required.

    -
    - -
    -

    Starting and Stopping Your Firewall

    +     Now modify /etc/shorewall/rules to add or remove +other connections as required.

    - -
    + +
    +

    Starting and Stopping Your Firewall

    +
    + +

    Arrow -     The installation procedure - configures your system to start Shorewall at system boot  but beginning -with Shorewall version 1.3.9 startup is disabled so that your system -won't try to start Shorewall before configuration is complete. Once you -have completed configuration of your firewall, you can enable Shorewall -startup by removing the file /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 + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
    -

    -
    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, +

    +
    + +
    +

    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 + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" + command. If you want to totally remove any trace of Shorewall from your Netfilter configuration, use "shorewall clear".

    -
    - -
    +
    + +

    -     The three-interface sample assumes that you want to enable - routing to/from eth1 (your local network) and eth2 (DMZ) - when Shorewall is stopped. If these two interfaces don't connect - to your local network and DMZ or if you want to enable a different - set of hosts, modify /etc/shorewall/routestopped accordingly.

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you - have added an entry for the IP address that you are connected from - to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to -create an alternate +     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.

    +
    + + - -

    Last updated 2/21/2003 - + +

    Last updated 5/19/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 - Thomas M. Eastep

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

    Copyright 2002, 2003 + Thomas M. Eastep
    +

    diff --git a/Shorewall-docs/three-interface_fr.html b/Shorewall-docs/three-interface_fr.html index 76d9e92d4..8571ef63f 100755 --- a/Shorewall-docs/three-interface_fr.html +++ b/Shorewall-docs/three-interface_fr.html @@ -1,1213 +1,1194 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    +

    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'à Tom EASTEP pour -son formidable outil et sa disponibilité).

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

    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 +
    • 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, +
    • 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' +

    + +

    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 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 situés dans le répertoire - /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec + 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 + href="Install.htm">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 + +

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

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

    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.

    - + - -

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

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

    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 +

    + +
    +

    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 l'Internet
      2. -
    2. drop (ignorer) toutes les demandes de connexion depuis l'Internet -vers votre firewall ou vers votre réseau local
      3. -
    3. Facultativement accepter toutes les demandes de connexion depuis -votre firewall et vers Internet (si vous decommentez la politique précédente)
      4. -
    4. reject (rejeter) toutes les autres demandes de connexion.
      5. - +
    5. permettre toutes demandes de connexion depuis le firewall vers +l'Internet
      6. +
    6. drop (ignorer) toutes les demandes de connexion depuis l'Internet + vers votre firewall ou vers votre réseau local
      7. +
    7. Facultativement accepter toutes les demandes de connexion depuis + votre firewall et vers Internet (si vous decommentez la politique précédente)
      8. +
    8. reject (rejeter) toutes les autres demandes de connexion.
      9. +
    - +

    - A ce point, éditez votre /etc/shorewall/policy et faites y les changements + 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 + 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 + +

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

    - + +

    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 +

    • +

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

    -
    - -
    +
    + +
    +

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

    + +

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

    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 +

    + +

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

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

    - + +

    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 +

    • +

      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 +

      • +
    • +

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

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

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

    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 +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server port>]<protocol><port>
    -
    -
    <protocol><port>
    +
    +
    -
    - -

    Si vous ne spécifiez pas le <server port>, il est supposé +

    + +

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

    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 +
    • 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 +
    • 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 + href="http://w.x.y.z:5000"> 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 +

    • +

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

    + +
    +

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

    + +
    +

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

    + +
    +

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

    + +
    +

    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
    ACCEPTnetfwtcp53#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) + +

    + +
    +

    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 +

    + +
    +

    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 +

    + +
    +

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

    +
    + +
    +

    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"; + 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 configuration alternativeet de la + href="configuration_file_basics.htm#Configs">alternativeet de la tester en utilisant la commande "shorewall try".

    -
    - -

    Last updated 12/20/2002 - + +

    Last updated 05/19/2003 - Tom Eastep

    - -

    Copyright 2002 Thomas - M. Eastep

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

    Copyright 2002, 2003 +Thomas M. Eastep
    +

    diff --git a/Shorewall-docs/two-interface.htm b/Shorewall-docs/two-interface.htm index ef6c48ab3..14192e6ff 100644 --- a/Shorewall-docs/two-interface.htm +++ b/Shorewall-docs/two-interface.htm @@ -1,1031 +1,1026 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
    +

    Basic Two-Interface Firewall

    -
    - -

    Setting up a Linux system as a firewall for a small network - is a fairly straight-forward task if you understand the basics -and follow the documentation.

    - -

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

    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.

    + +

    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:

    - +
      -
    • Linux system used as a firewall/router for a small +
    • Linux system used as a firewall/router for a small local network.
      • -
    • Single public IP address.
      • -
    • Internet connection through cable modem, DSL, ISDN, +
    • 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" +

    + +

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

    - -

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

    - -

    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:

    - +

    + +

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

    + +

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

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

    - +

    +

    -     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 two-interface sample, - un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to +     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).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration + +

    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 two-interface sample configuration, + +

    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:

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

    Zones are defined in the /etc/shorewall/zones + +

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

    - -

    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.

    - +
      -
    • You express your default policy for connections +
    • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
      • -
    • You define exceptions to those default policies +
    • You define exceptions to those default policies in the /etc/shorewall/rules file.
      • - +
    - -

    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 two-interface sample -has the following policies:

    - -
    + +

    The /etc/shorewall/policy file included with the two-interface sample has +the following policies:

    + +
    - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    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 +

    + +
    +

    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.

    - + - + + + + + + + + - - - - - - - - - - - - - - - + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    fwnetACCEPT  
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network +
    2. allow all connection requests from your local network to the internet
      3. -
    3. drop (ignore) all connection requests from the internet - to your firewall or local network
      4. -
    4. optionally accept all connection requests from the - firewall to the internet (if you uncomment the additional policy)
      5. -
    5. reject all other connection requests.
      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 +     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. +

    + +

    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.

    - +

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

    - -

    Your Internal Interface will be an ethernet adapter - (eth1 or eth0) and will be connected to a hub or switch. Your other - computers will be connected to the same hub/switch (note: If you -have only a single internal system, you can connect the firewall -directly to the computer using a cross-over cable).

    - + +

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

    +

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

      -
      • -
    • -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from +

    • +

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

    - -
    + +

    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:

    + +
         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 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, +     Before starting Shorewall, you should look at the + IP address of your external interface and if it is one of the above + ranges, you should remove the 'norfc1918' option from the external + interface's entry in /etc/shorewall/interfaces.

    +
    + +
    +

    You will want to assign your addresses from the same +sub-network (subnet).  For our purposes, we can consider a subnet + to consists of a range of addresses x.y.z.0 - x.y.z.255. Such +a subnet will have a Subnet Mask of 255.255.255.0. The address + x.y.z.0 is reserved as the Subnet Address and x.y.z.255 is + reserved as the Subnet Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing - (CIDR) notation with consists of the subnet address followed - by "/24". The "24" refers to the number of consecutive leading "1" + href="shorewall_setup_guide.htm#Subnets">Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive leading "1" bits from the left of the subnet mask.

    -
    - -
    +
    + +

    Example sub-network:

    -
    - -
    -
    +
    + +
    +
    - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    -
    - -
    -

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above + +

    + +
    +

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

    + +
    +

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

    - -

    The remainder of this quide will assume that you have configured +

    + +

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

    + +

    The remainder of this quide will assume that you have configured your network as shown here:

    - +

    -

    - +

    +

    The default gateway for 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 +     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 + +

    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.

    - -

    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:

    - + +

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

    • +

      Masquerade describes the case where you let your + firewall system automatically detect the external interface address.

      -
      • -
    • -

      SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local +

      • +
    • +

      SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local network to use.

      -
      • - + +
    - -

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. You will normally use -Masquerading if your external IP is dynamic and SNAT if the IP -is static.

    - + +

    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.

    +

    -     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 +     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, +     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
      • +
    • IP_FORWARDING=On
      +
      • +
    - +

    Port Forwarding (DNAT)

    - -

    One of your goals may be to run one or more servers on your - local computers. Because these computers have RFC-1918 addresses, - it is not possible for clients on the internet to connect directly -to them. It is rather necessary for those clients to address their -connection requests to the firewall who rewrites the destination address -to the address of your server and forwards the packet to that server. -When your server responds, the firewall automatically performs SNAT -to rewrite the source address in the response.

    - -

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure + +

    One of your goals may be to run one or more servers on your + local computers. Because these computers have RFC-1918 addresses, + it is not possible for clients on the internet to connect directly +to them. It is rather necessary for those clients to address their connection + requests to the firewall who rewrites the destination address to the + address of your server and forwards the packet to that server. When + your server responds, the firewall automatically performs SNAT to rewrite + the source address in the response.

    + +

    The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - -

    The general form of a simple port forwarding rule in /etc/shorewall/rules + +

    The general form of a simple port forwarding rule in /etc/shorewall/rules is:

    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - + + - - - - - - - + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:<server local ip address> [:<server + DNATnetloc:<server local ip address> [:<server port>]<protocol><port>  
    <protocol><port>  
    -
    - -

    Example - you run a Web Server on computer 2 and you want to forward incoming +

    + +

    Example - you run a Web Server on computer 2 and you want to forward incoming TCP port 80 to that system:

    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2tcp80  
    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 +
    • 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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2:80tcp5000  
    DNATnetloc:10.10.10.2:80tcp5000  
    -
    - +
    +

    -     At this point, modify /etc/shorewall/rules to add +     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:

    - + +

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

      -
      • - +     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
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    -
    - -
    +
    + +

    Other Connections

    -
    - -
    +
    + +

    The two-interface sample includes the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnettcp53  
    ACCEPTfwnetudp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnettcp53  
    ACCEPTfwnetudp53  
    -
    + +
    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you uncommented the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

    - -
    -

    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  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    -
    -
    - -
    -

    That rule allows you to run an SSH server on your firewall + +

    + +
    +

    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 +

    + +
    +

    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>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    -
    + +
    + +
    +

    Example - You want to run a Web Server on your firewall +system:

    - -
    -

    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 +

    +
    + +
    +

    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"

    -
    - -
    -

    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 +

    + +
    +

    If you don't know what port and protocol a particular application + uses, look here.

    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you want shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    + +
    + +

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible +     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.

    -
    - -
    -

    Starting and Stopping Your Firewall

    + +     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 +     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 + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
    -

    -
    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, +

    +
    + +
    +

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

    -
    - -
    + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" + command. If you want to totally remove any trace of Shorewall from + your Netfilter configuration, use "shorewall clear".

    +
    + +

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

    + + - +
    +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Eastep
    -

    -
    -
    -
    -
    +

    diff --git a/Shorewall-docs/upgrade_issues.htm b/Shorewall-docs/upgrade_issues.htm index b721cc87a..bce12679d 100755 --- a/Shorewall-docs/upgrade_issues.htm +++ b/Shorewall-docs/upgrade_issues.htm @@ -1,421 +1,441 @@ - + Upgrade Issues - + - + - + - + - - - + + - - - + + + +
    +
    +

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

    - +

    + +

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

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

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

    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:
    - -
      -
    • 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:
    - -
      -
    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. - -
    - 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?
    - -
    	[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
    - -     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:
    -
    - -
    - 
    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.
    - -

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

    - -

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

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

    - -

    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 forget - to backup root.lrp !
      4. - -
    - -

    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

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

    Versions >= 1.3.5

    - -

    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 4/13/2003 - Tom -Eastep

    - -

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

    -
    +

    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
    +

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

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

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

    + +

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

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

    + +

    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 +forget to backup root.lrp !
      4. + +
    + +

    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

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

    Versions >= 1.3.5

    + +

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

    diff --git a/Shorewall/changelog.txt b/Shorewall/changelog.txt index 69f8bc2d7..4e3e328a4 100755 --- a/Shorewall/changelog.txt +++ b/Shorewall/changelog.txt @@ -8,4 +8,6 @@ Changes since 1.4.3a 3. DNAT and REDIRECT logging is moved from the filter table to the nat table. +4. Don't include log rule number when LOGFORMAT doesn't include "%d". + diff --git a/Shorewall/fallback.sh b/Shorewall/fallback.sh index ce38e78f3..8f2c746b0 100755 --- a/Shorewall/fallback.sh +++ b/Shorewall/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.4.4 +VERSION=1.4.4a usage() # $1 = exit status { diff --git a/Shorewall/firewall b/Shorewall/firewall index 4d7b27227..5eae0f2a3 100755 --- a/Shorewall/firewall +++ b/Shorewall/firewall @@ -4484,14 +4484,20 @@ do_initialize() { if [ -n "$LOGFORMAT" ]; then if [ -n "`echo $LOGFORMAT | grep '%d'`" ]; then LOGRULENUMBERS=Yes - if ! qt printf "$LOGFORMAT" foo 1 bar ; then + temp=`printf "$LOGFORMAT" fooxx 1 barxx 2> /dev/null` + if [ $? -ne 0 ]; then startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\"" fi else - if ! qt printf "$LOGFORMAT" foo bar ; then + temp=`printf "$LOGFORMAT" fooxx barxx 2> /dev/null` + if [ $? -ne 0 ]; then startup_error "Invalid LOGFORMAT string: \"$LOGFORMAT\"" fi fi + + if [ ${#temp} -gt 29 ]; then + startup_error "LOGFORMAT string is too long: \"$LOGFORMAT\"" + fi else LOGFORMAT="Shorewall:%s:%s:" fi diff --git a/Shorewall/install.sh b/Shorewall/install.sh index b562d2492..09b6691a0 100755 --- a/Shorewall/install.sh +++ b/Shorewall/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.4.4 +VERSION=1.4.4a usage() # $1 = exit status { diff --git a/Shorewall/releasenotes.txt b/Shorewall/releasenotes.txt index 22fd3049b..efa8ced70 100755 --- a/Shorewall/releasenotes.txt +++ b/Shorewall/releasenotes.txt @@ -11,8 +11,10 @@ New Features: 2) The LOGMARKER variable has been renamed LOGFORMAT and has been changed to a 'printf' formatting template which accepts three - arguments (the chain name, logging rule number and the disposition). - To use LOGFORMAT with fireparse, set it as: + arguments (the chain name, logging rule number (optional) and the + disposition). The logging rule number is included if the LOGFORMAT + value contains '%d'. For example, to use LOGFORMAT with fireparse, + set it as: LOGFORMAT="fp=%s:%d a=%s " @@ -28,3 +30,4 @@ New Features: logging now takes place in the nat table rather than in the filter table. This way, only those connections that actually undergo DNAT or redirection will be logged. + diff --git a/Shorewall/shorewall.spec b/Shorewall/shorewall.spec index 18f5a92ca..8fad31c0d 100644 --- a/Shorewall/shorewall.spec +++ b/Shorewall/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.4.4 +%define version 1.4.4a %define release 1 %define prefix /usr @@ -105,6 +105,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Tue May 27 2003 Tom Eastep +- Changed version to 1.4.4a-1 * Thu May 22 2003 Tom Eastep - Changed version to 1.4.4-1 * Mon May 19 2003 Tom Eastep diff --git a/Shorewall/uninstall.sh b/Shorewall/uninstall.sh index 429cc2c31..e38f3710d 100755 --- a/Shorewall/uninstall.sh +++ b/Shorewall/uninstall.sh @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=1.4.4 +VERSION=1.4.4a usage() # $1 = exit status {