diff --git a/Lrp/etc/init.d/shorewall b/Lrp/etc/init.d/shorewall index e52387060..80a4adac3 100755 --- a/Lrp/etc/init.d/shorewall +++ b/Lrp/etc/init.d/shorewall @@ -4,7 +4,7 @@ # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # On most distributions, this file should be called: # /etc/rc.d/init.d/shorewall or /etc/init.d/shorewall @@ -374,7 +374,14 @@ chain_base() #$1 = interface { local c=${1%%+*} - echo ${c:=common} + case $c in + *.*) + echo ${c%.*}_${c#*.} + ;; + *) + echo ${c:=common} + ;; + esac } # @@ -599,13 +606,17 @@ validate_interfaces_file() { for option in $options; do case $option in - dhcp|noping|filterping|routestopped|norfc1918|multi|tcpflags) - ;; - routefilter|dropunclean|logunclean|blacklist|proxyarp|maclist|-) - ;; - *) - error_message "Warning: Invalid option ($option) in record \"$r\"" - ;; + dhcp|routestopped|norfc1918|multi|tcpflags) + ;; + routefilter|dropunclean|logunclean|blacklist|proxyarp|maclist|-) + ;; + noping|filterping) + [ -n "$OLD_PING_HANDLING" ] || \ + startup_error "Option $option only allowed with old ping handling" + ;; + *) + error_message "Warning: Invalid option ($option) in record \"$r\"" + ;; esac done @@ -1102,8 +1113,7 @@ validate_policy() # find_broadcasts() { for interface in $all_interfaces; do - interface=`chain_base $interface` - eval bcast=\$${interface}_broadcast + eval bcast=\$`chain_base $interface`_broadcast if [ "x$bcast" = "xdetect" ]; then addr="`ip addr show $interface 2> /dev/null`" if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then @@ -1122,7 +1132,7 @@ find_broadcasts() { # find_interface_broadcasts() # $1 = Interface name { - eval bcast=\$${1}_broadcast + eval bcast=\$`chain_base ${1}`_broadcast if [ "x$bcast" = "xdetect" ]; then addr="`ip addr show $interface 2> /dev/null`" @@ -1414,6 +1424,23 @@ setup_tunnels() # $1 = name of tunnels file echo " PPTP server defined." } + setup_one_openvpn() # $1 = gateway, $2 = kind[:port] + { + case $2 in + *:*) + p=${2#*:} + ;; + *) + p=5000 + ;; + esac + + addrule $inchain -p udp -s $1 --sport $p --dport $p -j ACCEPT + addrule $outchain -p udp -d $1 --sport $p --dport $p -j ACCEPT + + echo " OPENVPN tunnel to $1:$p defined." + } + strip_file tunnels $1 while read kind z gateway z1; do @@ -1441,6 +1468,9 @@ setup_tunnels() # $1 = name of tunnels file pptpserver|PPTPSERVER) setup_pptp_server ;; + openvpn|OPENVPN|openvpn:*|OPENVPN:*) + setup_one_openvpn $gateway $kind + ;; *) error_message "Tunnels of type $kind are not supported:" \ "Tunnel \"$tunnel\" Ignored" @@ -1704,8 +1734,11 @@ setup_nat() { while read external interface internal allints localnat; do expandv external interface internal allints localnat + + iface=${interface%:*} + if [ -n "$ADD_IP_ALIASES" ]; then - qt ip addr del $external dev $interface + qt ip addr del $external dev $iface fi if [ -z "$allints" -o "$allints" = "Yes" -o "$allints" = "yes" ] @@ -1718,9 +1751,9 @@ setup_nat() { -j DNAT --to-destination $internal fi else - addnatrule `input_chain $interface` \ + addnatrule `input_chain $iface` \ -d $external -j DNAT --to-destination $internal - addnatrule `output_chain $interface` \ + addnatrule `output_chain $iface` \ -s $internal -j SNAT --to-source $external fi @@ -1753,7 +1786,7 @@ delete_nat() { # # Process a TC Rule - $marking_chain is assumed to contain the name of the -# marking chain +# default marking chain # process_tc_rule() { @@ -1774,13 +1807,34 @@ process_tc_rule() ;; *) if ! list_search $source $all_interfaces; then - fatal_error "Error: Unknown interface $source" + fatal_error "Error: Unknown interface $source in rule \"$rule\"" fi r="-i $source " ;; esac fi + + if [ "$mark" != "${mark%:*}" ]; then + + [ "$chain" = tcout ] && \ + fatal_error "Chain designator not allowed when source is \$FW; rule \"$rule\"" + + case "${mark#*:}" in + p|P) + chain=tcpre + ;; + f|F) + chain=tcfor + ;; + *) + fatal_error "Invalid chain designator: (${mark#*:}) in rule \"$rule\"" + ;; + esac + + mark="${mark%:*}" + fi + [ "x$dest" = "x-" ] || r="${r}-d $dest " [ "$proto" = "all" ] || r="${r}-p $proto " [ "x$port" = "x-" ] || r="${r}--dport $port " @@ -1811,7 +1865,8 @@ setup_tc1() { # Create the TC mangle chains # - run_iptables -t mangle -N $marking_chain + run_iptables -t mangle -N tcpre + run_iptables -t mangle -N tcfor run_iptables -t mangle -N tcout # # Process the TC Rules File @@ -1827,11 +1882,9 @@ setup_tc1() { # Link to the TC mangle chains from the main chains # - if [ $marking_chain = tcfor ]; then - run_iptables -t mangle -A FORWARD -j tcfor - else - run_iptables -t mangle -A PREROUTING -j tcpre - fi + run_iptables -t mangle -A FORWARD -j tcfor + run_iptables -t mangle -A PREROUTING -j tcpre + run_iptables -t mangle -A OUTPUT -j tcout run_user_exit tcstart @@ -2871,6 +2924,21 @@ rules_chain() # $1 = source zone, $2 = destination zone fatal_error "Error: No appropriate chain for zone $1 to zone $2" } +# +# echo the list of subnets routed out of a given interface +# +get_routed_subnets() # $1 = interface name +{ + local address + local rest + + ip route show dev $1 2> /dev/null | + while read address rest; do + [ "$address" = "${address%/*}" ] && address="${address}/32" + echo $address + done +} + # # Set up Source NAT (including masquerading) # @@ -2879,12 +2947,32 @@ setup_masq() setup_one() { local using - if [ "$interface" = "${interface%:*}" ]; then - destnet="0.0.0.0/0" - else - destnet="${interface#*:}" - interface="${interface%:*}" - fi + case $fullinterface in + *:*:*) + # Both alias name and subnet + destnet="${fullinterface##*:}" + fullinterface="${fullinterface%:*}" + ;; + *:*) + # Alias name OR subnet + case ${fullinterface#*:} in + *.*) + # It's a subnet + destnet="${fullinterface#*:}" + fullinterface="${fullinterface%:*}" + ;; + *) + #it's an alias name + destnet="0.0.0.0/0" + ;; + esac + ;; + *) + destnet="0.0.0.0/0" + ;; + esac + + interface=${fullinterface%:*} if ! list_search $interface $all_interfaces; then fatal_error "Error: Unknown interface $interface" @@ -2900,10 +2988,10 @@ setup_masq() chain=`masq_chain $interface` iface= + source="$subnet" + case $subnet in *.*.*) - source="$subnet" - subnet="-s $subnet" ;; -) # @@ -2916,22 +3004,15 @@ setup_masq() iface="-o $interface" ;; *) - ipaddr="`ip addr show $subnet 2> /dev/null | grep 'inet '`" - source="$subnet" - if [ -z "$ipaddr" ]; then - fatal_error \ - "Interface $subnet must be up before Shorewall starts" - fi - - subnet="`echo $ipaddr | sed s/" "// | cut -d' ' -f2`" - [ -z "`echo "$subnet" | grep '/'`" ] && subnet="${subnet}/32" - subnet="-s $subnet" + subnets=`get_routed_subnets $subnet` + [ -z "$subnets" ] && startup_error "Unable to determine the routes through interface $subnet" + subnet="$subnets" ;; esac if [ -n "$address" -a -n "$ADD_SNAT_ALIASES" ]; then list_search $address $aliases_to_add || \ - aliases_to_add="$aliases_to_add $address $interface" + aliases_to_add="$aliases_to_add $address $fullinterface" fi destination=$destnet @@ -2939,7 +3020,15 @@ setup_masq() if [ -n "$nomasq" ]; then newchain=masq${masq_seq} createnatchain $newchain - addnatrule $chain -d $destnet $iface $subnet -j $newchain + + if [ -n "$subnet" ]; then + for s in $subnet; do + addnatrule $chain -d $destnet $iface -s $s -j $newchain + done + else + addnatrule $chain -d $destnet $iface -j $newchain + fi + masq_seq=$(($masq_seq + 1)) chain=$newchain subnet= @@ -2949,29 +3038,38 @@ setup_masq() for addr in `separate_list $nomasq`; do addnatrule $chain -s $addr -j RETURN done + + source="$source except $nomasq" else destnet="-d $destnet" fi - if [ -n "$address" ]; then - addnatrule $chain $subnet $destnet $iface \ - -j SNAT --to-source $address - using=" using $address" + if [ -n "$subnet" ]; then + for s in $subnet; do + if [ -n "$address" ]; then + addnatrule $chain -s $s $destnet $iface -j SNAT --to-source $address + echo " To $destination from $s through ${interface} using $address" + else + addnatrule $chain -s $s $destnet $iface -j MASQUERADE + echo " To $destination from $s through ${interface}" + fi + done + elif [ -n "$address" ]; then + addnatrule $chain $destnet $iface -j SNAT --to-source $address + echo " To $destination from $source through ${interface} using $address" else - addnatrule $chain $subnet $destnet $iface -j MASQUERADE - using= + addnatrule $chain $destnet $iface -j MASQUERADE + echo " To $destination from $source through ${interface}" fi - [ -n "$nomasq" ] && source="$source except $nomasq" - echo " To $destination from $source through ${interface}${using}" } strip_file masq $1 [ -n "$NAT_ENABLED" ] && echo "Masqueraded Subnets and Hosts:" - while read interface subnet address; do - expandv interface subnet address + while read fullinterface subnet address; do + expandv fullinterface subnet address [ -n "$NAT_ENABLED" ] && setup_one || \ error_message "Warning: NAT disabled; masq rule ignored" done < $TMP_DIR/masq @@ -3195,9 +3293,10 @@ add_ip_aliases() val=${val%% scope*} fi - run_ip addr add ${external}${val} dev $interface + run_ip addr add ${external}${val} dev $interface $label echo "$external $interface" >> ${STATEDIR}/nat - echo " IP Address $external added to interface $interface" + [ -n "$label" ] && label="with $label" + echo " IP Address $external added to interface $interface $label" } set -- $aliases_to_add @@ -3205,6 +3304,14 @@ add_ip_aliases() while [ $# -gt 0 ]; do external=$1 interface=$2 + label= + + if [ "$interface" != "${interface%:*}" ]; then + label="${interface#*:}" + interface="${interface%:*}" + label="label $interface:$label" + fi + primary=`find_interface_address $interface` shift;shift [ "x${primary}" = "x${external}" ] || do_one @@ -3350,11 +3457,14 @@ initialize_netfilter () { # Build the common chain -- called during [re]start and refresh # build_common_chain() { - # - # PING - # - [ -n "$FORWARDPING" ] && \ - run_iptables -A icmpdef -p icmp --icmp-type echo-request -j ACCEPT + + if [ -n "$OLD_PING_HANDLING" ]; then + # + # PING + # + [ -n "$FORWARDPING" ] && \ + run_iptables -A icmpdef -p icmp --icmp-type echo-request -j ACCEPT + fi # # Common ICMP rules # @@ -3907,23 +4017,25 @@ define_firewall() # $1 = Command (Start or Restart) process_rules $rules - echo "Setting up ICMP Echo handling..." + if [ -n "$OLD_PING_HANDLING" ]; then + echo "Setting up ICMP Echo handling..." - filterping_interfaces="`find_interfaces_by_option filterping`" - noping_interfaces="`find_interfaces_by_option noping`" + filterping_interfaces="`find_interfaces_by_option filterping`" + noping_interfaces="`find_interfaces_by_option noping`" - for interface in $all_interfaces; do - if ! list_search $interface $filterping_interfaces; then - if list_search $interface $noping_interfaces; then - target=DROP - else - target=ACCEPT + for interface in $all_interfaces; do + if ! list_search $interface $filterping_interfaces; then + if list_search $interface $noping_interfaces; then + target=DROP + else + target=ACCEPT + fi + + run_iptables -A `input_chain $interface` \ + -p icmp --icmp-type echo-request -j $target fi - - run_iptables -A `input_chain $interface` \ - -p icmp --icmp-type echo-request -j $target - fi - done + done + fi policy=`find_file policy` @@ -4104,7 +4216,7 @@ add_to_zone() # $1 = [:] $2 = zone dhcp_interfaces=`find_interfaces_by_option dhcp` blacklist_interfaces=`find_interfaces_by_option blacklist` filterping_interfaces=`find_interfaces_by_option filterping` - maclist_interfaces=`find_interfaces_by_maclist` + maclist_interfaces=`find_interfaces_by_option maclist` tcpflags_interfaces=`find_interfaces_by_option tcpflags` # # Normalize the first argument to this function @@ -4161,15 +4273,15 @@ add_to_zone() # $1 = [:] $2 = zone rulenum=2 fi - if ! list_search $interface $filterping_interfaces; then + if list_search $interface $filterping_interfaces; then rulenum=$(($rulenum + 1)) fi - if ! list_search $interface $maclist_interfaces; then + if list_search $interface $maclist_interfaces; then rulenum=$(($rulenum + 1)) fi - if ! list_search $interface $tcpflags_interfaces; then + if list_search $interface $tcpflags_interfaces; then rulenum=$(($rulenum + 1)) fi @@ -4194,11 +4306,11 @@ add_to_zone() # $1 = [:] $2 = zone rulenum=2 fi - if ! list_search $interface $maclist_interfaces; then + if list_search $interface $maclist_interfaces; then rulenum=$(($rulenum + 1)) fi - if ! list_search $interface $tcpflags_interfaces; then + if list_search $interface $tcpflags_interfaces; then rulenum=$(($rulenum + 1)) fi fi @@ -4344,7 +4456,7 @@ delete_from_zone() # $1 = [:] $2 = zone while read z1 z2 chain; do if [ "$z1" = "$zone" ]; then if [ "$z2" = "$FW" ]; then - qt iptables -D `input_chain $interface` -i $interface -s $host -j $chain + qt iptables -D `input_chain $interface` -s $host -j $chain else source_chain=`forward_chain $interface` eval dest_hosts=\"\$${z2}_hosts\" @@ -4471,6 +4583,7 @@ do_initialize() { TCP_FLAGS_LOG_LEVEL= RFC1918_LOG_LEVEL= MARK_IN_FORWARD_CHAIN= + OLD_PING_HANDLING= SHARED_DIR=/usr/lib/shorewall FUNCTIONS= VERSION_FILE= @@ -4596,7 +4709,10 @@ do_initialize() { else CLEAR_TC= fi + OLD_PING_HANDLING=`added_param_value_yes OLD_PING_HANDLING $OLD_PING_HANDLING` + [ -z "$OLD_PING_HANDLING" -a -n "$FORWARDPING" ] && \ + startup_error "FORWARDPING=Yes is incompatible with OLD_PING_HANDLING=No" run_user_exit params diff --git a/Lrp/etc/shorewall/interfaces b/Lrp/etc/shorewall/interfaces index 595d49581..070df08d1 100644 --- a/Lrp/etc/shorewall/interfaces +++ b/Lrp/etc/shorewall/interfaces @@ -46,18 +46,6 @@ # a DHCP server running on the firewall or # you have a static IP but are on a LAN # segment with lots of Laptop DHCP clients. -# noping - icmp echo-request (ping) packets -# addressed to the firewall should -# be ignored on this interface -# filterping - icmp echo-request (ping) packets -# addressed to the firewall should -# be controlled by the rules file and -# applicable policy. If neither 'noping' -# nor 'filterping' are specified then -# the firewall will respond to 'ping' -# requests. 'filterping' takes -# precedence over 'noping' if both are -# given. # routestopped - (Deprecated -- use # /etc/shorewall/routestopped) # When the firewall is stopped, allow @@ -117,15 +105,14 @@ # eth1 connected to your local network and that your # local subnet is 192.168.1.0/24. The interface gets # it's IP address via DHCP from subnet -# 206.191.149.192/27 and you want pings from the internet -# to be ignored. You interface a DMZ with subnet +# 206.191.149.192/27. You have a DMZ with subnet # 192.168.2.0/24 using eth2. You want to be able to # access the firewall from the local network when the # firewall is stopped. # # Your entries for this setup would look like: # -# net eth0 206.191.149.223 noping,dhcp +# net eth0 206.191.149.223 dhcp # local eth1 192.168.1.255 routestopped # dmz eth2 192.168.2.255 # diff --git a/Lrp/etc/shorewall/masq b/Lrp/etc/shorewall/masq index 3b0edea3e..0b8515619 100644 --- a/Lrp/etc/shorewall/masq +++ b/Lrp/etc/shorewall/masq @@ -9,7 +9,15 @@ # Columns are: # # INTERFACE -- Outgoing interface. This is usually your internet -# interface. This may be qualified by adding the character +# interface. If ADD_SNAT_ALIASES=Yes in +# /etc/shorewall/shorewall.conf, you may add ":" and +# a digit to indicate that you want the alias added with +# that name (e.g., eth0:0). This will allow the alias to +# be displayed with ifconfig. THAT IS THE ONLY USE FOR +# THE ALIAS NAME AND IT MAY NOT APPEAR IN ANY OTHER +# PLACE IN YOUR SHOREWALL CONFIGURATION. +# +# This may be qualified by adding the character # ":" followed by a destination host or subnet. # # @@ -17,7 +25,7 @@ # a subnet or as an interface. If you give the name of an # interface, you must have iproute installed and the interface # must be up before you start the firewall. -# +# # In order to exclude a subset of the specified SUBNET, you # may append "!" and a comma-separated list of IP addresses # and/or subnets that you wish to exclude. @@ -74,13 +82,12 @@ # Example 4: # # You want all outgoing traffic from 192.168.1.0/24 through -# eth0 to use source address 206.124.146.176. +# eth0 to use source address 206.124.146.176 which is NOT the +# primary address of eth0. You want 206.124.146.176 added to +# be added to eth0 with name eth0:0. # -# eth0 192.168.1.0/24 206.124.146.176 +# eth0:0 192.168.1.0/24 206.124.146.176 # -# This would normally be done when you have a static external -# IP address since it makes the processing of outgoing -# packets somewhat faster. ############################################################################## #INTERFACE SUBNET ADDRESS #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE diff --git a/Lrp/etc/shorewall/nat b/Lrp/etc/shorewall/nat index 7b6ba5b20..e791a8052 100644 --- a/Lrp/etc/shorewall/nat +++ b/Lrp/etc/shorewall/nat @@ -16,7 +16,13 @@ # IP address of the interface named in the next # column and must not be a DNS Name. # INTERFACE Interface that we want to EXTERNAL address to appear -# on +# on. If ADD_IP_ALIASES=Yes in shorewall.conf, you may +# follow the interface name with ":" and a digit to +# indicate that you want Shorewall to add the alias +# with this name (e.g., "eth0:0"). That allows you to +# see the alias with ifconfig. THAT IS THE ONLY THING +# THAT THIS NAME IS GOOD FOR -- YOU CANNOT USE IT +# ANYWHERE ELSE IN YOUR SHORWALL CONFIGURATION. # INTERNAL Internal Address (must not be a DNS Name). # 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 @@ -26,5 +32,5 @@ # Yes or yes, NAT will be effective from the firewall # system ############################################################################## -#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL +#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE diff --git a/Lrp/etc/shorewall/shorewall.conf b/Lrp/etc/shorewall/shorewall.conf index 8c2ec4f00..24c048975 100644 --- a/Lrp/etc/shorewall/shorewall.conf +++ b/Lrp/etc/shorewall/shorewall.conf @@ -401,12 +401,17 @@ MUTEX_TIMEOUT=60 LOGNEWNOTSYN= # -# Forward "Ping" +# Old Ping Handling # -# If FORWARDPING is set to "Yes" then Echo Request ("Ping") packets are -# forwarded by the firewall. - -FORWARDPING=Yes +# If this option is set to "Yes" then Shorewall will use its old ping handling +# facility including the FORWARDPING option in this file and the 'noping' and +# 'filterping' interface options. If this option is set to 'No' then ping +# is handled via policy and rules just like any other connection request. +# +# If you are a new Shorewall user DON'T CHANGE THE VALUE OF THIS OPTION AND +# DON'T DELETE IT!!!!!! +# +OLD_PING_HANDLING=No # # NEWNOTSYN @@ -502,4 +507,20 @@ RFC1918_LOG_LEVEL=info MARK_IN_FORWARD_CHAIN=No +# +# Clear Traffic Shapping/Control +# +# 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 omitted, CLEAR_TC=Yes is assumed. + +CLEAR_TC=Yes + #LAST LINE -- DO NOT REMOVE diff --git a/Lrp/etc/shorewall/tcrules b/Lrp/etc/shorewall/tcrules index d905a01ab..41d23120b 100644 --- a/Lrp/etc/shorewall/tcrules +++ b/Lrp/etc/shorewall/tcrules @@ -17,10 +17,20 @@ # MARK The mark value which is an # integer in the range 1-255 # +# May optionally be followed by ":P" or ":F" +# where ":P" indicates that marking should occur in +# the PREROUTING chain and ":F" indicates that marking +# should occur in the FORWARD chain. If neither +# ":P" nor ":F" follow the mark value then the chain is +# determined by the setting of MARK_IN_FORWARD_CHAIN in +# /etc/shorewall/shorewall.conf. +# # SOURCE Source of the packet. A comma-separated list of # interface names, IP addresses, MAC addresses # and/or subnets. Use $FW if the packet originates on -# the firewall. +# the firewall in which case the MARK column may NOT +# specify either ":P" or ":F" (marking always occurs +# in the OUTPUT chain). # # MAC addresses must be prefixed with "~" and use # "-" as a separator. diff --git a/Lrp/etc/shorewall/tunnels b/Lrp/etc/shorewall/tunnels index 5e961d6fd..86747729b 100644 --- a/Lrp/etc/shorewall/tunnels +++ b/Lrp/etc/shorewall/tunnels @@ -1,16 +1,21 @@ # # Shorewall 1.3 - /etc/shorewall/tunnels # -# This file defines IPSEC, GRE and IPIP tunnels. +# This file defines IPSEC, GRE, IPIP and OPENVPN tunnels. # -# IPIP and GRE tunnels must be configured on the firewall/gateway itself. -# IPSEC endpoints may be defined on the firewall/gateway or on an -# internal system. +# IPIP, GRE and OPENVPN tunnels must be configured on the +# firewall/gateway itself. IPSEC endpoints may be defined +# on the firewall/gateway or on an internal system. # # The columns are: # # TYPE -- must start in column 1 and be "ipsec", "ipsecnat","ip" -# "gre","pptpclient" or "pptpserver" +# "gre", "pptpclient", "pptpserver" or "openvpn". +# +# If type is "openvpn", it may optionally be followed +# by ":" and the port number used by the tunnel. if no +# ":" and port number are included, then the default port +# of 5000 will be used # # ZONE -- The zone of the physical interface through which # tunnel traffic passes. This is normally your internet @@ -20,10 +25,12 @@ # remote getway has no fixed address (Road Warrior) # then specify the gateway as 0.0.0.0/0. # -# GATEWAY ZONES -- Optional. If the gateway system specified in the third +# GATEWAY +# ZONES -- Optional. If the gateway system specified in the third # column is a standalone host then this column should -# contain a comma-separated list of the names of the zones that -# the host might be in. This column only applies to IPSEC tunnels. +# contain a comma-separated list of the names of the +# zones that the host might be in. This column only +# applies to IPSEC tunnels. # # Example 1: # @@ -71,5 +78,12 @@ # # pptpserver net # -# TYPE ZONE GATEWAY GATEWAY ZONE +# Example 7: +# +# OPENVPN tunnel. The remote gateway is 4.33.99.124 and +# openvpn uses port 7777. +# +# openvpn:7777 net 4.33.99.124 +# +# TYPE ZONE GATEWAY GATEWAY ZONE PORT #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE diff --git a/Lrp/etc/shorewall/zones b/Lrp/etc/shorewall/zones index 6d5add70c..45f103b73 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 # DISPLAY Display name of the zone # COMMENTS Comments about the zone # diff --git a/Lrp/sbin/shorewall b/Lrp/sbin/shorewall index 8b0e6b04f..3a2da0b91 100755 --- a/Lrp/sbin/shorewall +++ b/Lrp/sbin/shorewall @@ -4,7 +4,7 @@ # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # # This file should be placed in /sbin/shorewall. @@ -649,7 +649,7 @@ case "$1" in [ $# -ne 3 ] && usage 1 exec $FIREWALL $debugging $nolock $1 $2 $3 ;; - show) + show|list) [ $# -gt 2 ] && usage 1 case "$2" in connections) diff --git a/Lrp/var/lib/lrpkg/shorwall.version b/Lrp/var/lib/lrpkg/shorwall.version index 7962dcfdb..085c0f266 100644 --- a/Lrp/var/lib/lrpkg/shorwall.version +++ b/Lrp/var/lib/lrpkg/shorwall.version @@ -1 +1 @@ -1.3.13 +1.3.14 diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index 0aa6ae5f1..cfeb3947e 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,10 +1,22 @@ -Changes since 1.3.12 +Changes since 1.3.13 -1. Added 'DNAT-' target. +1. Fix 'shorewall add' bug. -2. Print policies in 'check' command. +2. Add OLD_PING_HANDLING option -3. Added CLEAR_TC option. +3. Allow adding alias labels under ADD_IP_ALIASES=Yes. -4. Added SHARED_DIR option. +4. Allow adding alias labels under ADD_SNAT_ALIASES=Yes. +5. Use the routing table to generate list of subnets to be masqueraded + when an interface name appears in the SUBNET column of + /etc/shorewall/masq. + +6. Restore $dev.$vid naming of VLAN interfaces. + +7. Updated copyrights for 2003. + +8. Added support for openvpn tunnels on arbitrary ports + +9. Corrected rule number calculation problem in 'shorewall add' command + processing. diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index dd7eb53d9..6561d1473 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -2,3297 +2,3490 @@ - + - + - + Shorewall 1.3 Documentation - - + + - + - + - - - + + - + + - - + +
+
- + +

Shorewall 1.3 Reference

-
- -

This documentation is intended primarily for reference. - Step-by-step instructions for configuring Shorewall in common - setups may be found in the 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.
    • -
  • functions -- a set of shell functions - used by both the firewall and shorewall shell programs. Installed - in /etc/shorewall prior to version 1.3.2, in /var/lib/shorewall in - version s 1.3.2-1.3.8 and in /usr/lib/shorewall in later versions.
    • -
  • modules -- a -parameter file installed in /etc/shorewall and that specifies -kernel modules and their parameters. Shorewall will automatically - load the modules specified in this file.
    • -
  • tos -- a parameter - file installed in /etc/shorewall that is used to specify -how the Type of Service (TOS) field in packets is to be set.
    • -
  • icmp.def -- a -parameter file installed in /etc/shorewall and that specifies -the default handling of ICMP packets when the applicable policy is - DROP or REJECT.
    • -
  • common.def -- a -parameter file installed in in /etc/shorewall that defines firewall-wide - rules that are applied before a DROP or REJECT policy is applied.
    • -
  • interfaces - -- a parameter file installed in /etc/shorewall/ and used - to describe the interfaces on the firewall system.
    • -
  • hosts -- a parameter - file installed in /etc/shorewall/ and used to describe - individual hosts or subnetworks in zones.
    • -
  • maclist -- a parameter -file installed in /etc/shorewall and used to verify the MAC address -(and possibly also the IP address(es)) of devices.
    -
    • -
  • masq - This file - also describes IP masquerading under Shorewall and is installed - in /etc/shorewall.
    • -
  • firewall - -- a shell program that reads the configuration files in - /etc/shorewall and configures your firewall. This file -is installed in your init.d directory (/etc/rc.d/init.d - ) where it is renamed shorewall. /etc/shorewall/firewall - (/var/lib/shorewall/firewall in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall - in 1.3.9 and later) is a symbolic link to this program.
    • -
  • nat -- a parameter - file in /etc/shorewall used to define static - NAT .
    • -
  • proxyarp -- -a parameter file in /etc/shorewall used to define Proxy Arp .
    • -
  • rfc1918 -- a parameter - file in /etc/shorewall used to define the treatment of packets under - the norfc1918 interface option.
    • -
  • routestopped - -- a parameter file in /etc/shorewall used to define those hosts - that can access the firewall when Shorewall is stopped.
    • -
  • tcrules - -- a parameter file in /etc/shorewall used to define rules - for classifying packets for Traffic - Shaping/Control.
    • -
  • tunnels -- a -parameter file in /etc/shorewall used to define IPSec tunnels.
    • -
  • shorewall --- a shell program (requiring a Bourne shell or derivative) - used to control and monitor the firewall. This should be - placed in /sbin or in /usr/sbin (the install.sh script and - the rpm install this file in /sbin).
    • -
  • version -- a file created in /etc/shorewall/ - (/var/lib/shorewall in version 1.3.2-1.3.8 and /usr/lib/shorewall - beginning in version 1.3.9) that describes the version of Shorewall - installed on your system.
    • - -
- -

/etc/shorewall/params

- -

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

- -

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=noping,norfc1918
- -

Example (/etc/shorewall/interfaces record):

- -
	net $NET_IF $NET_BCAST $NET_OPTIONS
- -

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

- -
	net eth0 130.252.100.255 noping,norfc1918
- -

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

- -

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

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

Components

-

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:

- +

Shorewall consists of the following components:

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

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

    - - - -

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

    - - - -

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

    - - - -

    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.

    - - - -

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

    - - -

    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 if - LOGUNCLEAN has not been set, "info" is assumed.

    - - -

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

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

My recommendations concerning options:
-

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

- -

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

+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + -
ZONE DISPLAY COMMENTS
netNetInternet
locLocalLocal networks
dmzDMZDemilitarized zone
- - - - - - - - - - - - - - - - - - - +
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,noping,norfc1918,blacklist
loceth1detect
-
+ + +

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": + +
      +
    • you must have iproute installed
      • +
    • the interface must be up before you start +your firewall
      • +
    • the interface must only be attached to + a single sub-network (i.e., there must have a single broadcast + address).
      • - - - - -
+ - -

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

+ +
  • OPTIONS - a comma-separated list + of options. Possible options include: - -
    - - - - - - - - - - - - - - - + +

    tcpflags (added in version 1.3.11) - This option causes Shorewall +to make sanity checks on the header flags in TCP packets arriving on this +interface. 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).

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

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

    + + + +

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

    + + + +

    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.

    + + + +

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

    - -

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

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

    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.

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

    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.

    - -

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

    + +

    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.

    - -

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

    - -

    Columns in this file are:

    - - -
      -
    • ZONE - A zone defined in the /etc/shorewall/zones file.
      • -
    • HOST(S) - The name of a network interface - followed by a colon (":") followed by either:
      • - + +

      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.

      + +
    + +

    My recommendations concerning options:
    +

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

    - + +

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

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

    routestopped - Beginning with Shorewall - 1.3.4, this option is deprecated in favor of the - /etc/shorewall/routestopped - file. When the firewall is stopped, traffic to and from - this host (these hosts) will be accepted and routing will -occur between this host and other routestopped interfaces - and hosts.
    -
    - maclist - Added in version 1.3.10. If specified, -connection requests from the hosts specified in this entry are subject -to 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 1: You probably DON'T -want to specify any hosts for your internet zone since the hosts that -you specify will be the only ones that you will be able to access without -adding additional rules.

    - - -

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

    - - -

    Example:

    - - -

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

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

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

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

    + +

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

    - -

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

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

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

    - - -

    Nested and Overlapping Zones

    - - -

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

    - - -

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

    - - -

    - /etc/shorewall/policy Configuration.

    - - -

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

    - - -

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

    - - -

    Four policies are defined:

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

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

    - - -

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

    - - -
      - -
    1. SOURCE - -The name of a client zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or "all").
      2. - -
    2. DEST - The - name of a destination zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or "all"). Shorewall automatically - allows all traffic from the firewall to itself so the name - of the firewall zone cannot appear in both the SOURCE and DEST columns.
      3. - -
    3. POLICY - -The default policy for connection requests from the SOURCE - zone to the DESTINATION zone.
      4. - -
    4. LOG LEVEL -- Optional. If left empty, no log message is generated when -the policy is applied. Otherwise, this column should contain an integer - or name indicating a syslog level.
      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
    -
    netppp0
    +
    +
    -
    +
    - -

    This table may be interpreted as follows:

    + +

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

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

    WARNING:

    - -

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

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

    - The CONTINUE policy

    - -

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

    - -

    /etc/shorewall/zones:

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

    /etc/shorewall/interfaces:

    - - +
    - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ZONE INTERFACE BROADCAST OPTIONS
    -eth0detectdhcp,noping,norfc1918
    loceth1detectroutestopped
    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: 90% of + Shorewall users don't need to put entries in this file and + 80% of those who try to add such entries do it wrong. + Unless you are ABSOLUTELY SURE that you need entries in + this file, don't touch it.

    + + +

    Columns in this file are:

    + + +
      +
    • ZONE - A zone defined in the /etc/shorewall/zones file.
      • +
    • HOST(S) - The name of a network +interface followed by a colon (":") followed by either:
      • + +
    + + +
    + + +
      + +
    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 options.
      • + +
    + + +
    + + +

    routestopped - Beginning with Shorewall + 1.3.4, this option is deprecated in favor of the + /etc/shorewall/routestopped + file. When the firewall is stopped, traffic to and from + this host (these hosts) will be accepted and routing will + occur between this host and other routestopped interfaces + and hosts.
    +
    + maclist - Added in version 1.3.10. If specified, + connection requests from the hosts specified in this entry are subject + to 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 1: You probably +DON'T want to specify any hosts for your internet zone since the hosts +that you specify will be the only ones that you will be able to access +without adding additional rules.

    + + +

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

    + + +

    Example:

    + + +

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

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

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

    /etc/shorewall/hosts:

    + +

    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
    neteth0:0.0.0.0/0
    -
    sameth0:206.191.149.197routestopped
    ZONE HOST(S) OPTIONS
    loc1eth1:192.168.1.0/25
    +
    loc2eth1:192.168.1.128/25routestopped
    +
    + + +

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

    + + +

    Nested and Overlapping +Zones

    + + +

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

    + + +

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

    + + +

    + /etc/shorewall/policy Configuration.

    + + +

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

    + + + +

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

    + + + +

    Four policies are defined:

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

    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.

    + +

    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.

    - -

    /etc/shorewall/policy:

    + +

    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:

    + + +
    + + - - - - - - - - - - - - - + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + - + - +
    SOURCE DEST POLICY LOG LEVEL
    locnetACCEPT
    -
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    +
    samallCONTINUE
    -
    netallDROPinfo
    allallREJECTinfo

    +
    netallDROPinfo
    +
    allallREJECTinfo
    +
    -
    - - -

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

    - - -

    Partial /etc/shorewall/rules:

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

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

    - - -

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

    - - -
    - -

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

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

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

    - - - -

    Entries in the file have the following columns:

    - -
      -
    • ACTION - -
        -
      • ACCEPT, DROP or REJECT. These have the same -meaning here as in the policy file above.
        • -
      • DNAT -- Causes the connection request to be -forwarded to the system specified in the DEST column (port -forwarding). "DNAT" stands for "Destination Network - Address Translation"
        • -
      • 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.
        • - - -
      - - -

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

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

    + +

    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
    +
    +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    netallDROPinfo
    +
    loclocREJECTinfo
    +
    DNATnetloc:192.168.1.3tcpssh
    -
    -
    +
    + + +

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

    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.

    + +

    /etc/shorewall/hosts:

    - -
    - + +
    + - + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + - + - - +
    ZONE HOST(S) OPTIONS
    neteth0:0.0.0.0/0
    +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    REDIRECTloc3128tcpwww -
    -     		!206.124.146.177
    ACCEPTfwnettcpwww
    -
    -
    sameth0:206.191.149.197routestopped
    -
    +
    - -

    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.

    + +

    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"> + - + - - - - - - - - + + + + + + + + + + + + - - - - - - - - - - + + + + + + - - - - - - - - - + + + + + + + + + + + + - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    SOURCE DEST POLICY LOG LEVEL
    locnetACCEPT
    +
    ACCEPTnetdmz:155.186.235.222tcpwww-
    -
    samallCONTINUE
    +
    ACCEPTlocdmz:155.186.235.222tcpwww
    -
    -
    netallDROPinfo
    allallREJECTinfo
    -
    - - -

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

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

    - - - -
    - - - -

    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.

    - - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACCEPTloc:~02-00-08-E3-FA-55dmzall
    -
    -
    -
    -
    - - - Example 6. - You wish to allow access to the SMTP server in your DMZ from all zones.
    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ACTION
    -     		SOURCE
    -     		DEST
    -     		PROTO
    -     		DEST
    - PORT(S)
    -     		SOURCE
    - PORT(S)
    -     		ORIGINAL
    - DEST
    -
    ACCEPT
    -     		all
    -     		dmz
    -     		tcp
    -     		25
    -
    -
    -
    -
    - 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
    -
    -
    -
    -
    - 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

    + +
    + + +

    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:

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

    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.

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

    + + +
    + +

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

    - /etc/shorewall/masq

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

    - -

    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 .

    + +

    + /etc/shorewall/rules

    - -

    Columns are:

    - + +

    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:

    +
      -
    • INTERFACE - The interface that will -masquerade the subnet; this is normally your internet interface. -This interface name can be optionally qualified by adding ":" -and a subnet or host IP. When this qualification is added, only -packets addressed to that host or subnet will be masqueraded.
      • -
    • SUBNET - The subnet that you want to -have masqueraded through the INTERFACE. This may be expressed -as a single IP address, a subnet or an interface name. In the latter - instance, the interface must be configured and started before Shorewall - is started as Shorewall will determine the subnet based on information - obtained from the 'ip' utility.
      -
      - The subnet may be optionally followed by "!' and - a comma-separated list of addresses and/or subnets that are to be - excluded from masquerading.
      • -
    • ADDRESS - The source address to be used - for outgoing packets. This column is optional and if left blank, - the current primary IP address of the interface in the first column - is used. If you have a static IP on that interface, listing it here - makes processing of output packets a little less expensive for -the firewall. 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.
      • - +
    • ACTION + + +
        +
      • ACCEPT, DROP or REJECT. These have the +same meaning here as in the policy file above.
        • +
      • DNAT -- Causes the connection request to + be forwarded to the system specified in the DEST column +(port forwarding). "DNAT" stands for "Destination Network + Address Translation"
        • +
      • 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.
        • + + + +
      + + + +

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

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

    - -
    + +
    - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - + - +
    INTERFACE SUBNETADDRESS
    eth0192.168.9.0/24
    -
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    DNATnetloc:192.168.1.3tcpssh
    +
    +
    -
    +
    - -

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

    - -
    + +
    - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - +
    INTERFACE SUBNETADDRESS
    ipsec0:10.1.0.0/16192.168.9.0/24
    -
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    REDIRECTloc3128tcpwww -
    +     		!206.124.146.177
    ACCEPTfwnettcpwww
    +
    +
    -
    - - -

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

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

    Example 4: - Same as example 3 - except that you wish - 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
    -
    - - -

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

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

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

    - - - -

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

    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:

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

    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.

    + + +
    + +
    ADDRESS INTERFACE EXTERNALHAVEROUTE
    155.186.235.4eth2eth0No
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTnetdmz:155.186.235.222tcpwww-
    +
    ACCEPTlocdmz:155.186.235.222tcpwww
    +
    +
    -
    +
    - -

    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.

    + +

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

    - -

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

    + +
    + + + - -

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

    - -

    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 .

    - - - - -

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

    Look here for additional information and an example. +

    -

    - -

    - /etc/shorewall/tunnels

    - - -

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

    - - -

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

    - - -

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

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

    + + + +
    + + + +

    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.

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTloc:~02-00-08-E3-FA-55dmzall
    +
    +
    +
    +
    + + + Example +6. You wish to allow access to the SMTP server in your DMZ from +all zones.
    + +
    + + + + + + + + + + + + + + + + + + + + + + + +
    ACTION
    +     		SOURCE
    +     		DEST
    +     		PROTO
    +     		DEST
    + PORT(S)
    +     		SOURCE
    + PORT(S)
    +     		ORIGINAL
    + DEST
    +
    ACCEPT
    +     		all
    +     		dmz
    +     		tcp
    +     		25
    +
    +
    +
    +
    + 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
    +
    +
    +
    +
    + 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.

    + + + + +

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

    + + + + +

    Columns are:

    + +
      +
    • INTERFACE - The interface that +will masquerade the subnet; this is normally your internet +interface. This interface name can be optionally qualified +by adding ":" and a subnet or host IP. When this qualification + is added, only packets addressed to that host or subnet will + be masqueraded. Beginning with Shorewall version 1.3.14, if you have set +ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf, +you can cause Shorewall to create an alias label of the form interfacename:digit + (e.g., eth0:0) by placing that label in this column. See example +5 below. Alias labels created in this way allow the alias to be visible to +the ipconfig utility. THAT IS THE ONLY THING THAT THIS LABEL IS GOOD +FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.
      • +
    • SUBNET - The subnet that you want + to have masqueraded through the INTERFACE. This may be expressed + as a single IP address, a subnet or an interface name. In the + latter instance, the interface must be configured and started +before Shorewall is started as Shorewall will determine the subnet + based on information obtained from the 'ip' utility. When using Shorewall 1.3.13 or earlier, when an interface + name is specified, Shorewall will only masquerade traffic from the first +subnetwork on the named interface; if the interface interfaces to more that +one subnetwork, you will need to add additional entries to this file for each +of those other subnetworks. Beginning with Shorewall 1.3.14, shorewall will +masquerade/SNAT traffic from any host that is routed through the named interface.
      +
      + The subnet may be optionally followed by "!' + and a comma-separated list of addresses and/or subnets that +are to be excluded from masquerading.
      • +
    • ADDRESS - The source address to be +used for outgoing packets. This column is optional and if left +blank, the current primary IP address of the interface in the +first column is used. If you have a static IP on that interface, listing + it here makes processing of output packets a little less expensive + for the firewall. If you specify an address in this column, it must be +an IP address configured on the INTERFACE or you must have ADD_SNAT_ALIASES + enabled in /etc/shorewall/shorewall.conf.
      • + +
    + + + +

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

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

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

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

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

    Example 4: + Same as example 3 + except that you wish + 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
    +
    + +

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

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

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

    + + + +

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

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

    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.

    + + +

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

    + + +

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

    + +

    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 .

    + + + + +

    + 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. Note: If two or more NATed +systems are connected to the same firewall interface and you +want them to be able to communicate using their EXTERNAL IP addresses, + then you will want to specify the multi option in the + /etc/shorewall/interface entry for that +interface.
      • +
    • LOCAL - If Yes or yes and the ALL +INTERFACES column contains Yes or yes, NAT will be effective +from the firewall system. Note: For this to work, +you must be running kernel 2.4.19 or later and iptables 1.2.6a or + later and you must have enabled CONFIG_IP_NF_NAT_LOCAL + in your kernel.
      • + +
    + + +

    Look here for additional information and an example. + +

    + + + +

    + /etc/shorewall/tunnels

    + + +

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

    + + +

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

    + + +

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

    +

    /etc/shorewall/shorewall.conf

    - +

    This file is used to set the following firewall parameters:

    - +
      -
    • 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 +
    • OLD_PING_HANDLING - Added at version + 1.3.14.
      + If this option is set to 'Yes' then the old and confusing ICMP echo-request + (Ping) handling is enabled. This includes the 'noping' and 'filterping' +interface options and the FORWARDPING option below. If this option is set +to "No" then ping requests are handled using rules and policies just like +any other connection request. For upward compatibility with only configurations, +if this option is omitted OLD_PING_HANDLING=Yes is assumed. New Shorewall +users should leave this option set to "No".
      +
      + For a complete description of how ping handling works under Shorewall, + see ping.html.
      +
      +
      • +
    • 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.
      • -
    • MACLIST_LOG_LEVEL - Added in Version 1.3.10
      - Determines the syslog level - for logging connection requests that fail MAC Verification. The value must be a valid - syslogd log level. If you don't want to log these connection requests, - set to the empty value (e.g., MACLIST_LOG_LEVEL="").
      -
      • -
    • NEWNOTSYN - Added in Version 1.3.8
      - When set to "Yes" or "yes", Shorewall will filter TCP packets - that are not part of an established connention and that are not SYN - packets (SYN flag on - ACK flag off). If set to "No", Shorewall will -silently drop such packets. If not set or set to the empty value (e.g., -"NEWNOTSYN="), NEWNOTSYN=No is assumed.
      -
      - If you have a HA setup with failover to another firewall, - you should have NEWNOTSYN=Yes on both firewalls. You should also select - NEWNOTSYN=Yes if you have asymmetric routing.
      -
      • -
    • FORWARDPING - Added in Version 1.3.7
      - When set to "Yes" or "yes", ICMP echo-request (ping) - packets from interfaces that specify "filterping" are ACCEPTed - by the firewall. When set to "No" or "no", such ping requests are - silently dropped unless they are handled by an explicit entry in - the rules file. If not specified, "No" is assumed.
      • -
    • LOGNEWNOTSYN - Added in Version 1.3.6
      - Beginning with version 1.3.6, Shorewall drops non-SYN - TCP packets that are not part of an existing connection. If -you would like to log these packets, set LOGNEWNOTSYN to the - syslog level at which you want - the packets logged. Example: LOGNEWNOTSYN=ULOG|
      -
      - Note: Packets logged under this option are -usually the result of broken remote IP stacks rather than the -result of any sort of attempt to breach your firewall.
      -
      • -
    • MERGE_HOSTS - Added in Version 1.3.5
      - Prior to 1.3.5, when the /etc/shorewall/hosts - file included an entry for a zone then the entire zone had to - be defined in the /etc/shorewall/hosts file and any associations - between the zone and interfaces in the /etc/shorewall/interfaces - file were ignored. This behavior is preserved if MERGE_HOSTS=No - or if MERGE_HOSTS is not set or is set to the empty value.
      -
      - Beginning with version 1.3.5, if MERGE_HOSTS=Yes, -then zone assignments in the /etc/shorewall/hosts file are ADDED -to those in the /etc/shorewall/interfaces file.
      -
      - Example:
      -
      - Interfaces File:
      +
    • 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.
      +
      • +
    • FORWARDPING - Added in Version 1.3.7 +- This option is deprecated and is not available when OLD_PING_HANDLING=No + (see above).
      + When set to "Yes" or "yes", ICMP echo-request +(ping) packets from interfaces that specify "filterping" are +ACCEPTed by the firewall. When set to "No" or "no", such ping +requests are silently dropped unless they are handled by an explicit +entry in the rules file. If not specified, "No" + is assumed. 
      • +
    • LOGNEWNOTSYN - Added in Version 1.3.6
      + Beginning with version 1.3.6, Shorewall drops +non-SYN TCP packets that are not part of an existing connection. +If you would like to log these packets, set LOGNEWNOTSYN to the + syslog level at which you want + the packets logged. Example: LOGNEWNOTSYN=ULOG|
      +
      + Note: Packets logged under this option +are usually the result of broken remote IP stacks rather than +the result of any sort of attempt to breach your firewall.
      +
      • +
    • MERGE_HOSTS - Added in Version 1.3.5
      + Prior to 1.3.5, when the /etc/shorewall/hosts + file included an entry for a zone then the entire zone had + to be defined in the /etc/shorewall/hosts file and any associations + between the zone and interfaces in the /etc/shorewall/interfaces file were +ignored. This behavior is preserved if MERGE_HOSTS=No or if MERGE_HOSTS + is not set or is set to the empty value.
      +
      + Beginning with version 1.3.5, if MERGE_HOSTS=Yes, + then zone assignments in the /etc/shorewall/hosts file are ADDED + to those in the /etc/shorewall/interfaces file.
      +
      + Example:
      +
      + Interfaces File:
      + - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - - + + +
      ZONEHOSTSBROADCASTOPTIONS
      loceth1-dhcp
      -ppp+
      -
      -
      ZONEHOSTSBROADCASTOPTIONS
      loceth1-dhcp
      -ppp+
      +
      +
      - -


      - Hosts File:
      -

      - + +


      + Hosts File:
      +

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


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

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

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

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

      -
      • -
    • NAT_BEFORE_RULES
      - If set to "No" or "no", port forwarding rules can -override the contents of the /etc/shorewall/nat -file. If set to "Yes" or "yes", port forwarding rules cannot override - static NAT. If not set or set to an empty value, "Yes" is assumed.
      • -
    • FW
      -       This - parameter - specifies the - name of the - firewall zone. - If not set or - if set to an - empty string, - the -value - "fw" - is assumed.
      • -
    • SUBSYSLOCK
      - This parameter should be set to the name of -a file that the firewall should create if it starts successfully - and remove when it stops. Creating and removing this file allows - Shorewall to work with your distribution's initscripts. For -RedHat, this should be set to /var/lock/subsys/shorewall. For -Debian, the value is /var/state/shorewall and in LEAF it is - /var/run/shorwall. - Example: - SUBSYSLOCK=/var/lock/subsys/shorewall.
      • -
    • STATEDIR
      - This parameter specifies the name of a directory - where Shorewall stores state information. If the directory - doesn't exist when Shorewall starts, it will create the directory. - Example: STATEDIR=/tmp/shorewall.
      -
      - NOTE: If you change the STATEDIR variable while - the firewall is running, create the new directory if necessary - then copy the contents of the old directory to the new directory. -
      • -
    • ALLOWRELATED
      - This parameter must be assigned the value "Yes" - ("yes") or "No" ("no") and specifies whether Shorewall -allows connection requests that are related to an already allowed -connection. If you say "No" ("no"), you can still override this -setting by including "related" rules in /etc/shorewall/rules ("related" - given as the protocol). If you specify ALLOWRELATED=No, you will -need to include rules in /etc/shorewall/icmpdef to - handle common ICMP packet types.
      • -
    • MODULESDIR
      - This parameter specifies the directory where -your kernel netfilter modules may be found. If you leave the -variable empty, Shorewall will supply the value "/lib/modules/`uname - -r`/kernel/net/ipv4/netfilter.
      • -
    • LOGRATE and LOGBURST
      - These parameters set the match rate and initial - burst size for logged packets. Please see the iptables man page - for a description of the behavior of these parameters (the iptables - option --limit is set by LOGRATE and --limit-burst is set by LOGBURST). - If both parameters are set empty, no rate-limiting will occur.
      -
      - Example:
      - LOGRATE=10/minute
      - LOGBURST=5
      -
      • -
    • LOGFILE
      + +

      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 - tells the - /sbin/shorewall - program where - to look for - Shorewall - messages when - processing the - "show - log", - "monitor", - "status" - and - "hits" - commands. - If not - assigned - or if assigned - an empty - value, - /var/log/messages - is assumed.
      • -
    • NAT_ENABLED
      - This parameter determines whether Shorewall -supports NAT operations. NAT operations include:
      -
      - Static NAT
      - Port Forwarding
      - Port Redirection
      - Masquerading
      -
      - If the parameter has no value or has a value -of "Yes" or "yes" then NAT is enabled. If the parameter has a -value of "no" or "No" then NAT is disabled.
      -
      • -
    • MANGLE_ENABLED
      - This parameter determines if packet mangling -is enabled. If the parameter has no value or has a value of -"Yes" or "yes" than packet mangling is enabled. If the parameter -has a value of "no" or "No" then packet mangling is disabled. If -packet mangling is disabled, the /etc/shorewall/tos file is ignored.
      -
      • -
    • IP_FORWARDING
      - This parameter determines whether Shorewall -enables or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). - Possible values are:
      -
      - On or on - packet forwarding will be enabled.
      - Off or off - packet forwarding will be disabled.
      - Keep or keep - Shorewall will neither enable - nor disable packet forwarding.
      -
      - If this variable is not set or is given an empty - value (IP_FORWARD="") then IP_FORWARD=On is assumed.
      -
      • -
    • ADD_IP_ALIASES
      - This parameter determines whether Shorewall automatically - adds the - external address(es) in /etc/shorewall/nat - . If the variable is set to "Yes" or "yes" then Shorewall -automatically adds these aliases. If it is set to "No" or -"no", you must add these aliases yourself using your distribution's -network configuration tools.
      +       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.

      - 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 + NOTE: If you change the STATEDIR variable + while the firewall is running, create the new directory if +necessary then copy the contents of the old directory to the +new directory.
      • +
    • ALLOWRELATED
      + This parameter must be assigned the value + "Yes" ("yes") or "No" ("no") and specifies whether Shorewall + allows connection requests that are related to an already +allowed connection. If you say "No" ("no"), you can still override +this setting by including "related" rules in /etc/shorewall/rules +("related" given as the protocol). If you specify ALLOWRELATED=No, +you will need to include rules in /etc/shorewall/icmpdef to + handle common ICMP packet types.
      • +
    • MODULESDIR
      + This parameter specifies the directory +where your kernel netfilter modules may be found. If you +leave the variable empty, Shorewall will supply the value +"/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
      • +
    • LOGRATE and LOGBURST
      + These parameters set the match rate and +initial burst size for logged packets. Please see the iptables +man page for a description of the behavior of these parameters +(the iptables option --limit is set by LOGRATE and --limit-burst +is set by LOGBURST). If both parameters are set empty, no rate-limiting +will occur.
      +
      + Example:
      + LOGRATE=10/minute
      + LOGBURST=5
      +
      • +
    • LOGFILE
      + + This parameter + tells the + /sbin/shorewall + program where + to look for + Shorewall + messages when + processing + the "show + log", + "monitor", + "status" + and + "hits" + commands. + If not + assigned + or if assigned + an empty + value, + /var/log/messages + is assumed.
      • +
    • NAT_ENABLED
      + This parameter determines whether Shorewall + supports NAT operations. NAT operations include:
      +
      + Static NAT
      + Port Forwarding
      + Port Redirection
      + Masquerading
      +
      + If the parameter has no value or has a +value of "Yes" or "yes" then NAT is enabled. If the parameter +has a value of "no" or "No" then NAT is disabled.
      +
      • +
    • MANGLE_ENABLED
      + This parameter determines if packet mangling + is enabled. If the parameter has no value or has a value + of "Yes" or "yes" than packet mangling is enabled. If the parameter + has a value of "no" or "No" then packet mangling is disabled. + If packet mangling is disabled, the /etc/shorewall/tos file +is ignored.
      +
      • +
    • IP_FORWARDING
      + This parameter determines whether Shorewall + enables or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). + Possible values are:
      +
      + On or on - packet forwarding will be + enabled.
      + Off or off - packet forwarding will +be disabled.
      + Keep or keep - Shorewall will neither + enable nor disable packet forwarding.
      +
      + If this variable is not set or is given +an empty value (IP_FORWARD="") then IP_FORWARD=On is assumed.
      +
      • +
    • ADD_IP_ALIASES
      + This parameter determines whether Shorewall + automatically adds the + external address(es) in + /etc/shorewall/nat . If the variable + is set to "Yes" or "yes" then Shorewall automatically adds +these aliases. If it is set to "No" or "no", you must add these +aliases yourself using your distribution's network configuration tools.
      -
      - If this variable is not set or is given an empty - value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is -assumed.
      -
      • -
    • LOGUNCLEAN
      +
      + If this variable is not set or is given +an empty value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes + is assumed.
      • +
    • ADD_SNAT_ALIASES
      + This parameter determines whether Shorewall automatically + adds the SNAT ADDRESS in /etc/shorewall/masq. + If the variable is set to "Yes" or "yes" then Shorewall automatically + adds these addresses. If it is set to "No" or "no", you must + add these addresses yourself using your distribution's network + configuration tools.
      +
      + If this variable is not set or is given +an empty value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No + is assumed.
      +
      • +
    • LOGUNCLEAN
      - This parameter - determines the - logging level - of - mangled/invalid - packets - controlled by - the 'dropunclean - and logunclean' - interface - options. If - LOGUNCLEAN - is empty - (LOGUNCLEAN=) - then - packets - selected by - 'dropclean' are - dropped - silently - ('logunclean' - packets are - logged under - the 'info' log - level). - Otherwise, - these + 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 - are logged at - the specified - level - (Example: - LOGUNCLEAN=debug).
      • -
    • BLACKLIST_DISPOSITION
      + from + blacklisted + hosts are not + logged.
      • +
    • CLAMPMSS
      - 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".
      • - + 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

    + +

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

    + +

    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>

    -
    + +

    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:

    + +

    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>

    -
    + +

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

    +
    - -

    - /etc/shorewall/tos Configuration

    + +

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

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

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

    +
    +
    + + + +

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

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

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

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

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

    - - + 
          130.252.100.69
          206.124.146.0/24
    - -

    Packets - from - hosts - listed - in - - the - blacklist - file - will - be + +

    Packets + from + hosts + listed + in + + the + blacklist + file + will + be disposed of @@ -3303,15 +3496,15 @@ one of the following:

    • value assigned to - the BLACKLIST_DISPOSITION - - and BLACKLIST_LOGLEVEL variables - - in - /etc/shorewall/shorewall.conf. - Only - packets + the BLACKLIST_DISPOSITION + + and BLACKLIST_LOGLEVEL variables + in + /etc/shorewall/shorewall.conf. + Only + packets + arriving on interfaces @@ -3329,172 +3522,192 @@ one of the following: against the - blacklist. The black list is designed to prevent -listed hosts/subnets from accessing services on your - network.
    -

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

    + +

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

    - + +

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

    - -

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

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

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

    - - - - -

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

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

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

    - - - - -
    +

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

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

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

    + + + + + +

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

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

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

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

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

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

    Updated 1/13/2003 - Tom Eastep -

    +
    + +

    Updated 3/4/2003 - Tom Eastep +

    - + +

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

    +
    +
    +
    +

    -

    -
    -
    +
    +



    diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index 376151c69..401f1db4d 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -2,1089 +2,1256 @@ - + + - + + - + + - + + Shorewall FAQ + - + + - - - + + - + + - - + + +
    +
    - + +

    Shorewall FAQs

    -
    - -

    1. I want to forward UDP - port 7777 to my my personal PC with IP address 192.168.1.5. - I've looked everywhere and can't find how to do it.

    - -

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

    - -

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

    - -

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

    - -

    2a. I have a zone "Z" with an RFC1918 - subnet and I use static NAT to assign non-RFC1918 addresses - to hosts in Z. Hosts in Z cannot communicate with each other - using their external (non-RFC1918 addresses) so they can't -access each other using their DNS names.

    - -

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

    - -

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

    - -

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

    - -

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

    - -

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

    + +

    1. I want to forward UDP + port 7777 to my my personal PC with IP address 192.168.1.5. + I've looked everywhere and can't find how to do it.

    + + +

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

    + + +

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

    +

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

    + + +

    2a. I have a zone "Z" with an RFC1918 + subnet and I use static NAT to assign non-RFC1918 + addresses to hosts in Z. Hosts in Z cannot communicate with + each other using their external (non-RFC1918 addresses) so they + can't access each other using their DNS names.

    + + +

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

    + + +

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

    + + +

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

    + + +

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

    + + +

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

    + +

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

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

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

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

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

    - + work?

    + +

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

    - + on RedHat     I get messages about insmod failing -- what's + wrong?

    + +

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

    - + my interfaces properly?

    + +

    10. What distributions does - it work with?

    - + it work with?

    + +

    11. What features does it support?

    - -

    12. Why isn't there a GUI

    - + + +

    12. Is there a GUI?

    + +

    13. Why do you call it "Shorewall"?

    - + +

    14. I'm connected via a cable modem - and it has an internel web server that allows me to configure/monitor - it but as expected if I enable rfc1918 blocking for -my eth0 interface, it also blocks the cable modems web server.

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

    - + IP addresses, my ISP's DHCP server has an RFC 1918 address. + If I enable RFC 1918 filtering on my external interface, my + DHCP client cannot renew its lease.

    + +

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

    - + out to the net

    + +

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

    - 17. How do - I find out why this traffic is getting logged?
    -
    - 18. Is there any way to use - aliased ip addresses with Shorewall, and maintain separate - rulesets for different IPs?
    -
    - 19. I have added entries to -/etc/shorewall/tcrules but they don't seem to do anything. -Why?
    -
    - 20. I have just set up a server. - Do I have to change Shorewall to allow access to my server from -the internet?
    -
    -     21. I see these strange log entries - occasionally; what are they?
    -
    - 22. I have some iptables commands that - I want to run when Shorewall starts. Which file do I put them in?
    -
    - 23. Why do you use such ugly fonts on - your web site?
    -
    - 24: How can I allow conections to let's -say the ssh port only from specific IP Addresses on the internet?
    - -
    + all over my console making it unusable!
    +

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

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

    - + do port forwarding under Shorewall. The format of a port-forwarding + rule to a local system is as follows:

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

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

    - + the rule is:

    + +
    - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - + + - +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:192.168.1.5udp7777
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:192.168.1.5udp7777
    +
    +
    -
    - + + +
    If - you want to forward requests directed to a particular address ( <external - IP> ) on your firewall to an internal system:
    - + you want to forward requests directed to a particular address ( <external + IP> ) on your firewall to an internal system: + +
    - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - + + - +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:<local IP address>[:<local - port>]<protocol><port #>-<external IP>
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:<local IP address>[:<local + port>]<protocol><port #>-<external IP>
    -
    - + + +Finally, if you need to forward a range of ports, in the PORT column specify +the range as low-port:high-port.
    +

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

    - + but it doesn't work + +

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

    - + +
      -
    • You are trying to test from inside -your firewall (no, that won't work -- see FAQ -#2).
      • -
    • You have a more basic problem with -your local system such as an incorrect default gateway configured -(it should be set to the IP address of your firewall's internal -interface).
      • - +
    • You are trying to test from inside + your firewall (no, that won't work -- see FAQ #2).
      • +
    • You have a more basic problem +with your local system such as an incorrect default gateway +configured (it should be set to the IP address of your firewall's +internal interface).
      • + +
    - + +

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

    - Answer: To further diagnose this problem:
    - + forwarding + Answer: To further diagnose this problem:
    +
      -
    • As root, type "iptables -t nat -Z". This clears - the NetFilter counters in the nat table.
      • -
    • Try to connect to the redirected port from an -external host.
      • -
    • As root type "shorewall show nat"
      • -
    • Locate the appropriate DNAT rule. It will be -in a chain called zone_dnat where zone is the -zone that includes the ('net' in the above examples).
      • -
    • Is the packet count in the first column non-zero? - If so, the connection request is reaching the firewall and is being - redirected to the server. In this case, the problem is usually -a missing or incorrect default gateway setting on the server (the -server's default gateway should be the IP address of the firewall's -interface to the server).
      • -
    • If the packet count is zero:
      • +
    • As root, type "iptables -t nat -Z". This + clears the NetFilter counters in the nat table.
      • +
    • Try to connect to the redirected port from + an external host.
      • +
    • As root type "shorewall show nat"
      • +
    • Locate the appropriate DNAT rule. It will + be in a chain called <source zone>_dnat ('net_dnat' + in the above examples).
      • +
    • Is the packet count in the first column +non-zero? If so, the connection request is reaching the firewall +and is being redirected to the server. In this case, the problem +is usually a missing or incorrect default gateway setting on the +server (the server's default gateway should be the IP address of +the firewall's interface to the server).
      • +
    • If the packet count is zero:
      • - +
        -
      • the connection request is not reaching your -server (possibly it is being blocked by your ISP); or
        • -
      • you are trying to connect to a secondary IP -address on your firewall and your rule is only redirecting the primary -IP address (You need to specify the secondary IP address in the "ORIG. - DEST." column in your DNAT rule); or
        • -
      • your DNAT rule doesn't match the connection -request in some other way. In that case, you may have to use a packet -sniffer such as tcpdump or ethereal to further diagnose the problem.
        -
        • +
      • the connection request is not reaching + your server (possibly it is being blocked by your ISP); or
        • +
      • you are trying to connect to a secondary + IP address on your firewall and your rule is only redirecting +the primary IP address (You need to specify the secondary IP address + in the "ORIG. DEST." column in your DNAT rule); or
        • +
      • your DNAT rule doesn't match the connection + request in some other way. In that case, you may have to use a + packet sniffer such as tcpdump or ethereal to further diagnose the + problem.
        +
        • - +
      - +
    - +

    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.

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

    Answer: I have two objections to this setup.

    - + +
      -
    • Having an internet-accessible server - in your local network is like raising foxes in the corner -of your hen house. If the server is compromised, there's nothing - between that server and your other internal systems. For the - cost of another NIC and a cross-over cable, you can put your -server in a DMZ such that it is isolated from your local systems - - assuming that the Server can be located near the Firewall, of course - :-)
      • -
    • The accessibility problem is best solved - using Bind Version - 9 "views" (or using a separate DNS server for local clients) such - that www.mydomain.com resolves to 130.141.100.69 externally and -192.168.1.5 internally. That's what I do here at shorewall.net for -my local systems that use static NAT.
      • - +
    • Having an internet-accessible +server in your local network is like raising foxes in the +corner of your hen house. If the server is compromised, there's + nothing between that server and your other internal systems. + For the cost of another NIC and a cross-over cable, you can put + your server in a DMZ such that it is isolated from your local +systems - assuming that the Server can be located near the Firewall, + of course :-)
      • +
    • The accessibility problem is +best solved using Bind +Version 9 "views" (or using a separate DNS server for local +clients) such that www.mydomain.com resolves to 130.141.100.69 +externally and 192.168.1.5 internally. That's what I do here at + shorewall.net for my local systems that use static NAT.
      • + +
    - + +

    If you insist on an IP solution to the accessibility problem - rather than a DNS solution, then assuming that your external - interface is eth0 and your internal interface is eth1 and that - eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24, do - the following:

    - + rather than a DNS solution, then assuming that your external + interface is eth0 and your internal interface is eth1 and + that eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24, + do the following:

    + +

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

    - -
    + for eth1 (No longer required as of Shorewall version 1.3.9).

    + + +

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

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

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

    -
    - -
    + IP address. If you have a dynamic IP address and are running + Shorewall 1.3.4 or later then include this in /etc/shorewall/params:

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

    and make your DNAT rule:

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

    Using this technique, you will want to configure your DHCP/PPPoE - client to automatically restart Shorewall each time that you - get a new IP address.

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

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

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

    - + static NAT to Proxy ARP. That way, the hosts in Z have +non-RFC1918 addresses and can be accessed externally and +internally using the same address.

    + +

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

    - + +

    a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces - (If you are running a Shorewall version earlier than 1.3.9).
    - b) Set the Z->Z policy to ACCEPT.
    - c) Masquerade Z to itself.
    -
    - Example:

    - + (If you are running a Shorewall version earlier than 1.3.9).
    + b) Set the Z->Z policy to ACCEPT.
    + c) Masquerade Z to itself.
    +
    + Example:

    + +

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

    - + Interface: eth2
    + Subnet: 192.168.2.0/24

    + +

    In /etc/shorewall/interfaces:

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

    In /etc/shorewall/policy:

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

    In /etc/shorewall/masq:

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

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

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

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

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

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

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

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

    - + section about UDP scans. If nmap gets nothing +back from your firewall then it reports the port as open. +If you want to see which UDP ports are really open, temporarily + change your net->all policy to REJECT, restart Shorewall and + do the nmap UDP scan again.

    + +

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

    - + can't ping through the firewall + +

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

    - + for "ping":

    + +

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

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

    + +
    - +

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

    -
    - For a complete description of Shorewall 'ping' management, see this page. - + -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?

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

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

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

    - + with Shorewall? + +

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

    - +

    + +
    - +

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

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

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

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

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

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

    - + I get messages about insmod failing -- what's wrong? + +

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

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

    -
    - + for problems concerning the version of iptables (v1.2.3) + shipped with RH7.2.

    +
    + +

    - +

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

    - + properly? + +

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

    - -
    + I see the following:

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

    Why can't Shorewall detect my interfaces properly?

    -
    - -
    +
    + + +

    Answer: The above output is perfectly normal. The Net zone is defined as all hosts that are connected through eth0 and the local zone is defined as all hosts connected through eth1

    -
    - +
    + +

    10. What Distributions does it work with?

    - + +

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

    - + the proper prerequisites.

    +

    11. What Features does it have?

    - + +

    Answer: See the Shorewall - Feature List.

    - -

    12. Why isn't there a GUI?

    - -

    Answer: Every time I've started to work on one, I find -myself doing other things. I guess I just don't care enough if Shorewall -has a GUI to invest the effort to create one myself. There are several -Shorewall GUI projects underway however and I will publish links to -them when the authors feel that they are ready.

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

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

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

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

    -
    - -
    + following to /etc/shorewall/rfc1918:

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

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

    - +

    +

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

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

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

    14a. Even though it assigns public IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC 1918 filtering on my external interface, my DHCP client cannot renew its lease.

    -
    - -
    +
    + + +

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

    -
    - + the IP address of your ISPs DHCP server.

    +
    + +

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

    - + 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 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 IP address of the local firewall interface.

        +
        3. +
      3. - + +

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

        -
        4. -
      4. + file is wrong or missing.

        +
        5. +
      5. - + +

        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.

        -
        6. - + user is running a DNS server on the firewall and hasn't + enabled UDP and TCP port 53 from the firewall to the internet.

        + + +
      - + +

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

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

      - + 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:
      - + 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 /etc/shorewall/rfc1918.
        2. -
      2. 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 aman1918 - The destination address + is listed in /etc/shorewall/rfc1918 with a logdrop target + -- see /etc/shorewall/rfc1918.
        4. +
      4. rfc1918 - The source address + is listed in /etc/shorewall/rfc1918 with a logdrop target + -- see /etc/shorewall/rfc1918.
        5. +
      5. 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.
        -
        6. -
      6. <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.
        7. -
      7. <interface>_mac - The packet is being - logged under the maclist +
      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 +
      11. logpkt - The packet is being + logged under the logunclean interface option.
        12. -
      12. badpkt - The packet is being logged - under the dropunclean badpkt - The packet is being + logged under the dropunclean interface option as specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
        13. -
      13. blacklst - The packet is being logged - because the source IP is blacklisted in theblacklst - The packet is being + logged because the source IP is blacklisted in the /etc/shorewall/blacklist file.
        14. -
      14. newnotsyn - The packet is being logged - because it is a TCP packet that is not part of any current connection - yet it is not a syn packet. Options affecting the logging of such - packets include NEWNOTSYN and LOGNEWNOTSYN - in /etc/shorewall/shorewall.conf.
        15. -
      15. INPUT or FORWARD - The packet - has a source IP address that isn't in any of your defined zones - ("shorewall check" and look at the printed zone definitions) or -the chain is FORWARD and the destination IP isn't in any of your defined - zones.
        16. -
      16. logflags - The packet is being logged because - it failed the checks implemented by the tcpflags 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.
        17. +
      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 by the tcpflags interface option.
        -
        19. - + +
      - +

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

      - Answer: Yes. You simply use the IP address -in your rules (or if you use NAT, use the local IP address in your -rules). Note: The ":n" notation (e.g., eth0:0) is deprecated -and will disappear eventually. Neither iproute (ip and tc) nor iptables -supports that notation so neither does Shorewall.
      -
      - Example 1:
      -
      - /etc/shorewall/rules + with Shorewall, and maintain separate rulesets for different + IPs? + Answer: Yes. You simply use the IP address + in your rules (or if you use NAT, use the local IP address in + your rules). Note: The ":n" notation (e.g., eth0:0) is deprecated + and will disappear eventually. Neither iproute (ip and tc) nor + iptables supports that notation so neither does Shorewall.
      +
      + Example 1:
      +
      + /etc/shorewall/rules + 
           # Accept AUTH but only on address 192.0.2.125

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

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

           DNAT	net	loc:10.1.1.127	tcp	smtp	-	192.0.2.127
      - +

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

      - You probably haven't set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf - so the contents of the tcrules file are simply being ignored.
      - + 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
      + + 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?
      -

      - -
      + what are they?
      + + +
      + 
      Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00
           SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3 
           [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]
      -
      - 192.0.2.3 is external on my firewall... 172.16.0.0/24 is -my internal LAN
      -
      - Answer: While most people associate the Internet Control - Message Protocol (ICMP) with 'ping', ICMP is a key piece of the internet. - ICMP is used to report problems back to the sender of a packet; this - is what is happening here. Unfortunately, where NAT is involved (including - SNAT, DNAT and Masquerade), there are a lot of broken implementations. - That is what you are seeing with these messages.
      -
      - Here is my interpretation of what is happening -- to confirm - this analysis, one would have to have packet sniffers placed a both -ends of the connection.
      -
      - Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a -UDP DNS query to 192.0.2.3 and your DNS server tried to send a response - (the response information is in the brackets -- note source port 53 which - marks this as a DNS reply). When the response was returned to to 206.124.146.179, - it rewrote the destination IP TO 172.16.1.10 and forwarded the packet -to 172.16.1.10 who no longer had a connection on UDP port 2857. This causes - a port unreachable (type 3, code 3) to be generated back to 192.0.2.3. - As this packet is sent back through 206.124.146.179, that box correctly - changes the source address in the packet to 206.124.146.179 but doesn't - reset the DST IP in the original DNS response similarly. When the ICMP - reaches your firewall (192.0.2.3), your firewall has no record of having - sent a DNS reply to 172.16.1.10 so this ICMP doesn't appear to be related - to anything that was sent. The final result is that the packet gets logged - and dropped in the all2all chain. I have also seen cases where the source - IP in the ICMP itself isn't set back to the external IP of the remote NAT - gateway; that causes your firewall to log and drop the packet out of the - rfc1918 chain because the source IP is reserved by RFC 1918.
      - +
      + 192.0.2.3 is external on my firewall... 172.16.0.0/24 + is my internal LAN
      +
      + Answer: While most people associate the Internet + Control Message Protocol (ICMP) with 'ping', ICMP is a key piece + of the internet. ICMP is used to report problems back to the sender + of a packet; this is what is happening here. Unfortunately, where NAT + is involved (including SNAT, DNAT and Masquerade), there are a lot +of broken implementations. That is what you are seeing with these messages.
      +
      + Here is my interpretation of what is happening -- to +confirm this analysis, one would have to have packet sniffers placed +a both ends of the connection.
      +
      + Host 172.16.1.10 behind NAT gateway 206.124.146.179 +sent a UDP DNS query to 192.0.2.3 and your DNS server tried to +send a response (the response information is in the brackets -- note +source port 53 which marks this as a DNS reply). When the response was +returned to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10 +and forwarded the packet to 172.16.1.10 who no longer had a connection +on UDP port 2857. This causes a port unreachable (type 3, code 3) to +be generated back to 192.0.2.3. As this packet is sent back through 206.124.146.179, + that box correctly changes the source address in the packet to 206.124.146.179 + but doesn't reset the DST IP in the original DNS response similarly. + When the ICMP reaches your firewall (192.0.2.3), your firewall has +no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't + appear to be related to anything that was sent. The final result is + that the packet gets logged and dropped in the all2all chain. I have also + seen cases where the source IP in the ICMP itself isn't set back to the + external IP of the remote NAT gateway; that causes your firewall to log + and drop the packet out of the rfc1918 chain because the source IP is + reserved by RFC 1918.
      +

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

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

      + +
      - Last updated 1/8/2003 - Last updated 2/6/2003 - Tom Eastep - +

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

      -
      -
      +

      diff --git a/STABLE/documentation/Install.htm b/STABLE/documentation/Install.htm index 1c3c4f4bf..9438668ed 100644 --- a/STABLE/documentation/Install.htm +++ b/STABLE/documentation/Install.htm @@ -1,207 +1,221 @@ - + Shorewall Installation - + - + - + - - - - - - + + + + + +
      -

      Shorewall Installation and -Upgrade

      -
      +

      Shorewall Installation and + Upgrade

      +
      - +

      Before upgrading, be sure to review the Upgrade Issues

      - +

      Install using RPM
      - Install using tarball
      - Upgrade using RPM
      - Upgrade using tarball
      - 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>).
        -
        - Note: 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>).
        • -
      • 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"
        • - +
      • Install the RPM (rpm -ivh <shorewall rpm>).
        +
        + Note: 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>).
        • +
      • 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:

      - + +

      To install Shorewall using the tarball + and install script:

      + - -

      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.3 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.3 (you must use the new -1.3 syntax). See the upgrade issues for details. -You can check your rules and host file for 1.3 compatibility using the "shorewall -check" command after installing the latest version of 1.3.

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

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

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

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

      - -

      If you are upgrading from a 1.2 version of Shorewall to a 1.3 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.3 (you must use the new -1.3 syntax). See the upgrade issues for -details. You can check your rules and host file for 1.3 compatibility using + +

      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.3 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.3 (you must use the +new 1.3 syntax). See the upgrade issues for +details. You can check your rules and host file for 1.3 compatibility using the "shorewall check" command after installing the latest version of 1.3.

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

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

        +
      • 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"
        • - +
      • Restart the firewall (shorewall restart).
        • +
      - -

      Configuring Shorewall

      - -

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

      - + +

      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.3 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.3 (you must use the +new 1.3 syntax). See the upgrade issues +for details. You can check your rules and host file for 1.3 compatibility +using the "shorewall check" command after installing the latest version +of 1.3.

      +
        -
      • /etc/shorewall/shorewall.conf - used to set several firewall - parameters.
        • -
      • /etc/shorewall/params - use this file to set shell variables that -you will expand in other files.
        • -
      • /etc/shorewall/zones - partition the firewall's view of the world - into zones.
        • -
      • /etc/shorewall/policy - establishes firewall high-level policy.
        • -
      • /etc/shorewall/interfaces - describes the interfaces on the - firewall system.
        • -
      • /etc/shorewall/hosts - allows defining zones in terms of individual - hosts and subnetworks.
        • -
      • /etc/shorewall/maclist - verification of the MAC addresses of devices.
        -
        • -
      • /etc/shorewall/masq - directs the firewall where to use many-to-one - (dynamic) NAT a.k.a. Masquerading.
        • -
      • /etc/shorewall/modules - directs the firewall to load kernel modules.
        • -
      • /etc/shorewall/rules - defines rules that are exceptions to the - overall policies established in /etc/shorewall/policy.
        • -
      • /etc/shorewall/nat - defines static NAT rules.
        • -
      • /etc/shorewall/proxyarp - defines use of Proxy ARP.
        • -
      • /etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines -hosts accessible when Shorewall is stopped.
        • -
      • /etc/shorewall/tcrules - defines marking of packets for later use -by traffic control/shaping.
        • -
      • /etc/shorewall/tos - defines rules for setting the TOS field in packet - headers.
        • -
      • /etc/shorewall/tunnels - defines IPSEC tunnels with end-points on - the firewall system.
        • -
      • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC addresses.
        • - +
      • 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"
        • +
      - -

      Updated 10/28/2002 - Tom Eastep -

      - -

      Copyright - © 2001, 2002 Thomas M. Eastep.

      -
      + 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 these configuration files to match + your setup. In most cases, the Shorewall QuickStart Guides +contain all of the information you need.

      + +
        +
      • /etc/shorewall/shorewall.conf - used to set several firewall + parameters.
        • +
      • /etc/shorewall/params - use this file to set shell variables that + you will expand in other files.
        • +
      • /etc/shorewall/zones - partition the firewall's view of the world + into zones.
        • +
      • /etc/shorewall/policy - establishes firewall high-level policy.
        • +
      • /etc/shorewall/interfaces - describes the interfaces on the + firewall system.
        • +
      • /etc/shorewall/hosts - allows defining zones in terms of individual + hosts and subnetworks.
        • +
      • /etc/shorewall/maclist - verification of the MAC addresses of devices.
        +
        • +
      • /etc/shorewall/masq - directs the firewall where to use many-to-one + (dynamic) NAT a.k.a. Masquerading.
        • +
      • /etc/shorewall/modules - directs the firewall to load kernel modules.
        • +
      • /etc/shorewall/rules - defines rules that are exceptions to the + overall policies established in /etc/shorewall/policy.
        • +
      • /etc/shorewall/nat - defines static NAT rules.
        • +
      • /etc/shorewall/proxyarp - defines use of Proxy ARP.
        • +
      • /etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines + hosts accessible when Shorewall is stopped.
        • +
      • /etc/shorewall/tcrules - defines marking of packets for later use + by traffic control/shaping.
        • +
      • /etc/shorewall/tos - defines rules for setting the TOS field in +packet headers.
        • +
      • /etc/shorewall/tunnels - defines IPSEC tunnels with end-points on + the firewall system.
        • +
      • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC addresses.
        • + +
      + +

      Updated 1/30/2003 - Tom Eastep +

      + +

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

      +
      +

      diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index e46e810a4..e27dd03e3 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -2,1975 +2,2380 @@ - + + Shorewall News - + - + + - + + - - - + + - + + - - + + +
      +
      - + +

      Shorewall News Archive

      -
      - -

      1/13/2003 - Shorewall 1.3.13
      -

      -

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

      + + +

      2/8/2003 - Shoreawll 1.3.14

      +

      New features include

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

        5. -
      5. The 'shorewall check' command now prints out the applicable policy -between each pair of zones.
        +
      6. Support for VLAN devices with names of the form $DEV.$VID (e.g., eth0.0)

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

      1/6/2003 - BURNOUT (New) -

      +


      +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

      -

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

      +

      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

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

      1/17/2003 - shorewall.net has MOVED 

      + +

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

      + +

      1/13/2003 - Shorewall 1.3.13
      +

      + +

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

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

      1/6/2003 - BURNOUT +

      + +

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

      +

      -Tom Eastep
      -

      - +

      +

      12/30/2002 - Shorewall Documentation in PDF Format

      - -

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

      - + +

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

      +

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

      - +

      +

      12/27/2002 - Shorewall 1.3.12 Released

      - +

      Features include:
      -

      - +

      +
        -
      1. "shorewall refresh" now reloads the traffic shaping rules (tcrules - and tcstart).
        2. -
      2. "shorewall debug [re]start" now turns off debugging after an error - occurs. This places the point of the failure near the end of the trace -rather than up in the middle of it.
        3. -
      3. "shorewall [re]start" has been speeded up by more than 40% with - my configuration. Your milage may vary.
        4. -
      4. A "shorewall show classifiers" command has been added which shows - the current packet classification filters. The output from this command - is also added as a separate page in "shorewall monitor"
        5. -
      5. ULOG (must be all caps) is now accepted as a valid syslog level - and causes the subject packets to be logged using the ULOG target rather - than the LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) - and log all Shorewall messages 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. - +
      9. "shorewall refresh" now reloads the traffic shaping rules + (tcrules and tcstart).
        10. +
      10. "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.
        11. +
      11. "shorewall [re]start" has been speeded up by more than +40% with my configuration. Your milage may vary.
        12. +
      12. 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"
        13. +
      13. 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.
        14. +
      14. 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.
        15. +
      15. 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.
        16. +
      16. 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.
        +
        17. +
      - +

      12/20/2002 - Shorewall 1.3.12 Beta 3
      -

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

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

      12/20/2002 - Shorewall 1.3.12 Beta 2

      - -

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

      - Features include:
      - + +

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

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

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

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

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

      12/7/2002 - Shorewall Support for Mandrake 9.0

      - -

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

      - + +

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

      +

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

      - +

      + +

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

      - +

      12/3/2002 - Shorewall 1.3.11a

      - -

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

      - + +

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

      +

      11/24/2002 - Shorewall 1.3.11

      - +

      In this version:

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

      11/14/2002 - Shorewall Documentation in PDF Format

      - -

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

      - + +

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

      +

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

      - -

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

      - +

      + +

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

      + +

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

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

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

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

      + +

      10/9/2002 - Shorewall 1.3.9b

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

      9/16/2002 - Shorewall 1.3.8

      +

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

      + Roles up the fix for broken tunnels.
      +

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

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

      9/28/2002 - Shorewall 1.3.9

      +

      In this version:
      -

      - +

      +
        -
      • A NEWNOTSYN - option has been added to shorewall.conf. This option determines - whether Shorewall accepts TCP packets which are not part of -an established connection and that are not 'SYN' packets (SYN -flag on and ACK flag off).
        • -
      • The need for the 'multi' option to -communicate between zones za and zb on the same interface -is removed in the case where the chain 'za2zb' and/or 'zb2za' -exists. 'za2zb' will exist if:
        • - - -
          -
        • There is a policy for za to - zb; or
          • -
        • There is at least one rule for -za to zb.
          • - - -
        - +
      • 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:
      +

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

      9/11/2002 - Debian 1.3.7c Packages Available

      - +

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

      - +

      9/2/2002 - Shorewall 1.3.7c

      - -

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

      + +

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

      - +

      8/31/2002 - I'm not available

      - -

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

      + +

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

      - +

      -Tom

      - +

      8/26/2002 - Shorewall 1.3.7b

      - -

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

      + +

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

      - +

      8/26/2002 - French FTP Mirror is Operational

      - +

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

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

      - +

      8/25/2002 - Shorewall Mirror in France

      - -

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

      + +

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

      - +

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

      - -

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

      - -

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

      +

      - -

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

      + +

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

      - +

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

      - +

      Features in this release include:

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

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

      + +

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

      - +

      8/13/2002 - Documentation in the CVS Repository

      - -

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

      + +

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

      - +

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

      - -

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

      + +

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

      - -

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

      + +

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

      - -

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

      + +

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

      - +

      8/7/2002 - Shorewall 1.3.6

      - +

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

      - + - + +

      7/30/2002 - Shorewall 1.3.5b Released

      - +

      This interim release:

      - + - + +

      7/29/2002 - New Shorewall Setup Guide Available

      - +

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

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

      - +

      7/28/2002 - Shorewall 1.3.5 Debian Package Available

      - -

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

      - +

      7/27/2002 - Shorewall 1.3.5a Released

      - +

      This interim release restores correct handling of REDIRECT rules.

      - +

      7/26/2002 - Shorewall 1.3.5 Released

      - -

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

      + +

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

      - +

       In this version:

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

      7/16/2002 - New Mirror in Argentina

      - -

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

      + +

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

      - +

      7/16/2002 - Shorewall 1.3.4 Released

      - +

      In this version:

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

      7/8/2002 - Shorewall 1.3.3 Debian Package Available

      - +

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

      - +

      7/6/2002 - Shorewall 1.3.3 Released

      - +

      In this version:

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

      6/25/2002 - Samples Updated for 1.3.2

      - -

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

      + +

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

      - +

      6/25/2002 - Shorewall 1.3.1 Debian Package Available

      - +

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

      - +

      6/19/2002 - Documentation Available in PDF Format

      - -

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

      + +

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

      - +

      6/16/2002 - Shorewall 1.3.2 Released

      - +

      In this version:

      - + - + +

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

      - -

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

      + +

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

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

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

      - -

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

      + +

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

      - + +

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

      + +

      6/5/2002 - Shorewall 1.3.1 Debian Package Available

      - +

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

      - +

      6/2/2002 - Samples Corrected

      - -

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

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

      5/19/2002 - Shorewall 1.3 Beta 2 Available

      - -

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

      + +

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

      - +
        -
      • The structure of the firewall is -changed markedly. There is now an INPUT and a FORWARD -chain for each interface; this reduces the number of rules that - a packet must traverse, especially in complicated setups.
        • -
      • 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:

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

      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.
        • -
      • SNAT - is now supported.
        • -
      • A "shorewall version" command has -been added
        • -
      • The default value of the STATEDIR -variable in /etc/shorewall/shorewall.conf has been changed -to /var/lib/shorewall in order to conform to the GNU/Linux - File Hierarchy Standard, Version 2.2.
        • - +
      • The installation problems +have been corrected.
        • +
      • SNAT is now supported.
        • +
      • A "shorewall version" command + has been added
        • +
      • The default value of the +STATEDIR variable in /etc/shorewall/shorewall.conf has +been changed to /var/lib/shorewall in order to conform to +the GNU/Linux File Hierarchy Standard, Version 2.2.
        • + +
      - + +

      1/28/2002 - Shorewall 1.2.4 Released

      - +
        -
      • The "fw" zone 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.
        • - +
      • 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:

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

      The following problems were corrected:

      - + +
        -
      • The "shorewall status" command no -longer hangs.
        • -
      • The "shorewall 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 Shorewall -download page.

      + href="mailto:lorenzo.martignoni@milug.org">Lorenzo Martignoni, a 1.2.2 + Shorewall Debian package is now available. There is a +link to Lorenzo's site from the Shorewall + download page.

      - +

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

      + href="/pub/shorewall/errata/1.2.2/shorewall">This corrected version restores + the "shorewall status" command to health.

      - +

      1/8/2002 - Shorewall 1.2.2 Released

      - +

      In version 1.2.2

      - +
        -
      • Support for IP blacklisting has been - added +
      • Support for IP blacklisting + has been added - + +
          -
        • You specify whether you want packets - from blacklisted hosts dropped or rejected using the - BLACKLIST_DISPOSITION - setting in /etc/shorewall/shorewall.conf
          • -
        • You specify whether you want packets - from blacklisted hosts logged and at what syslog level - using the BLACKLIST_LOGLEVEL - setting in /etc/shorewall/shorewall.conf
          • -
        • You list the IP addresses/subnets - that you wish to blacklist in You 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 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 http://www.shorewall.net/mailman/listinfo/shorewall-users.

      + +

      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

      +
    2. Logging of Mangled/Invalid + Packets is added. 
      3. +
    3. The tunnel + script has been corrected.
      4. +
    4. 'shorewall show tc' now correctly + handles tunnels.
      5. - + + + + +

      12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist releasing +1.2 on 12/21/2001

      + +

      Version 1.2 contains the following new features:

      - + - -

      For the next month or so, I will continue to provide corrections to version - 1.1.18 as necessary so that current version 1.1.x users will - not be forced into a quick upgrade to 1.2.0 just to have access - to bug fixes.

      - -

      For those of you who have installed one of the Beta RPMS, you will need - to use the "--oldpackage" option when upgrading to 1.2.0:

      - -
      - -

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

      -
      +
    5. Support for Filtering of Mangled/Invalid +Packets
      6. +
    6. Support for GRE Tunnels
      7. - -

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

      For the next month or so, I will continue to provide corrections to version + 1.1.18 as necessary so that current version 1.1.x users + will not be forced into a quick upgrade to 1.2.0 just to +have access to bug fixes.

      + + +

      For those of you who have installed one of the Beta RPMS, you will need + to use the "--oldpackage" option when upgrading to 1.2.0:

      + + +
      + +

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

      +
      + + +

      12/19/2001 - Thanks to Steve + Cowles, there is now a Shorewall mirror in Texas. + This web site is mirrored at http://www.infohiiway.com/shorewall + and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

      - +

      11/30/2001 - A new set of the parameterized Sample - Configurations has been released. In this version:

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

      - -

      Updated 1/13/2003 - Tom Eastep -

      - + + +

      3/8/2001 - The current version of Shorewall is 1.0.2. It supports an + additional "gw" (gateway) zone for tunnels and it +supports IPSEC tunnels with end-points on the firewall. +There is also a .lrp available now.

      + + +

      Updated 2/7/2003 - Tom Eastep +

      + +

      Copyright © 2001, 2002 Thomas M. Eastep.
      -

      +

      +
      +
      +



      diff --git a/STABLE/documentation/Shorewall_CA_html.html b/STABLE/documentation/Shorewall_CA_html.html index 10f1e9a18..df64c0309 100644 --- a/STABLE/documentation/Shorewall_CA_html.html +++ b/STABLE/documentation/Shorewall_CA_html.html @@ -2,90 +2,92 @@ Shorewall Certificate Authority - + - + - + - - - - - - + + + + + +
      - -

      Shorewall Certificate Authority -(CA) Certificate

      -
      + +

      Shorewall Certificate Authority + (CA) Certificate

      +
      -
      - Given that I develop and support Shorewall without asking for any renumeration, -I can hardly justify paying $200US+ a year to a Certificate Authority such -as Thawte (A Division of VeriSign) for an X.509 certificate to prove that -I am who I am. I have therefore established my own Certificate Authority (CA) -and sign my own X.509 certificates. I use these certificates on my mail server -(https://mail.shorewall.net) +
      + Given that I develop and support Shorewall without asking for any renumeration, + I can hardly justify paying $200US+ a year to a Certificate Authority such + as Thawte (A Division of VeriSign) for an X.509 certificate to prove that + I am who I am. I have therefore established my own Certificate Authority +(CA) and sign my own X.509 certificates. I use these certificates on my list +server (https://lists.shorewall.net) which hosts parts of this web site.
      -
      - X.509 certificates are the basis for the Secure Socket Layer (SSL). As part -of establishing an SSL session (URL https://...), your browser verifies the -X.509 certificate supplied by the HTTPS server against the set of Certificate -Authority Certificates that were shipped with your browser. It is expected -that the server's certificate was issued by one of the authorities whose identities -are known to your browser.
      -
      - This mechanism, while supposedly guaranteeing that when you connect to https://www.foo.bar -you are REALLY connecting to www.foo.bar, means that the CAs literally have -a license to print money -- they are selling a string of bits (an X.509 certificate) -for $200US+ per year!!!I
      -
      - I wish that I had decided to become a CA rather that designing and writing -Shorewall.
      -
      - What does this mean to you? It means that the X.509 certificate that my -server will present to your browser will not have been signed by one of the -authorities known to your browser. If you try to connect to my server using -SSL, your browser will frown and give you a dialog box asking if you want +
      + X.509 certificates are the basis for the Secure Socket Layer (SSL). As +part of establishing an SSL session (URL https://...), your browser verifies +the X.509 certificate supplied by the HTTPS server against the set of Certificate + Authority Certificates that were shipped with your browser. It is expected + that the server's certificate was issued by one of the authorities whose +identities are known to your browser.
      +
      + This mechanism, while supposedly guaranteeing that when you connect to +https://www.foo.bar you are REALLY connecting to www.foo.bar, means that +the CAs literally have a license to print money -- they are selling a string +of bits (an X.509 certificate) for $200US+ per year!!!I
      +
      + I wish that I had decided to become a CA rather that designing and writing + Shorewall.
      +
      + What does this mean to you? It means that the X.509 certificate that my +server will present to your browser will not have been signed by one of the +authorities known to your browser. If you try to connect to my server using +SSL, your browser will frown and give you a dialog box asking if you want to accept the sleezy X.509 certificate being presented by my server.
      -
      - There are two things that you can do:
      - +
      + There are two things that you can do:
      +
        -
      1. You can accept the mail.shorewall.net certificate when your browser -asks -- your acceptence of the certificate can be temporary (for that access -only) or perminent.
        2. -
      2. You can download and install my (self-signed) CA -certificate. This will make my Certificate Authority known to your browser +
      3. You can accept the mail.shorewall.net certificate when your browser + asks -- your acceptence of the certificate can be temporary (for that access + only) or perminent.
        4. +
      4. You can download and install my (self-signed) CA +certificate. This will make my Certificate Authority known to your browser so that it will accept any certificate signed by me.
        -
        5. - + +
      - What are the risks?
      - + What are the risks?
      +
        -
      1. If you install my CA certificate then you assume that I am trustworthy -and that Shorewall running on your firewall won't redirect HTTPS requests -intented to go to your bank's server to one of my systems that will present -your browser with a bogus certificate claiming that my server is that of -your bank.
        2. -
      2. If you only accept my server's certificate when prompted then the -most that you have to loose is that when you connect to https://mail.shorewall.net, -the server you are connecting to might not be mine.
        3. - +
      3. If you install my CA certificate then you assume that I am trustworthy + and that Shorewall running on your firewall won't redirect HTTPS requests + intented to go to your bank's server to one of my systems that will present +your browser with a bogus certificate claiming that my server is that of your +bank.
        4. +
      4. If you only accept my server's certificate when prompted then the +most that you have to loose is that when you connect to https://mail.shorewall.net, + the server you are connecting to might not be mine.
        5. +
      - I have my CA certificate loaded into all of my browsers but I certainly + I have my CA certificate loaded into all of my browsers but I certainly won't be offended if you decline to load it into yours... :-)
      - -

      Last Updated 12/29/2002 - Tom Eastep

      - + +

      Last Updated 1/17/2003 - Tom Eastep

      +

      Copyright © 2001, 2002 Thomas M. Eastep.

      + size="2">Copyright © 2001, 2002, 2003 Thomas +M. Eastep.

      +


      diff --git a/STABLE/documentation/Shorewall_Squid_Usage.html b/STABLE/documentation/Shorewall_Squid_Usage.html index 6a35828e7..a310704f3 100644 --- a/STABLE/documentation/Shorewall_Squid_Usage.html +++ b/STABLE/documentation/Shorewall_Squid_Usage.html @@ -2,407 +2,489 @@ Shorewall Squid Usage - + - + - + - - - + - + - - - +
      + + + +
      +
      -
      -
      +       		Using Shorewall with Squid
      -       		+ -
      -
      -
      - This page covers Shorewall configuration to use with Squid running as a Transparent +
      + This page covers Shorewall configuration to use with Squid running as a Transparent Proxy. 
      -
      -
      + Caution -     Please observe the following general requirements:
      -
      - -     In all cases, Squid should be configured to run +     Please observe the following general requirements:
      +
      + +     In all cases, Squid should be configured to run as a transparent proxy as described at http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html.
      -
      -       -     The following instructions mention the files /etc/shorewall/start - and /etc/shorewall/init -- if you don't have those files, siimply create +
      +       +     The following instructions mention the files /etc/shorewall/start + and /etc/shorewall/init -- if you don't have those files, siimply create them.
      -
      - -     When the Squid server is in the DMZ zone or in -the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts - file entries. That is because the packets being routed to the Squid server +
      + +     When the Squid server is in the DMZ zone or in +the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts + file entries. That is because the packets being routed to the Squid server still have their original destination IP addresses.
      -
      - -     You must have iproute2 (ip utility) installed +
      + +     You must have iproute2 (ip utility) installed on your firewall.
      -
      - -     You must have iptables installed on your Squid +
      + +     You must have iptables installed on your Squid server.
      -
      - -     You must have NAT and MANGLE enabled in your /etc/shorewall/conf +
      + +     You must have NAT and MANGLE enabled in your /etc/shorewall/conf file
      -
      -         NAT_ENABLED=Yes
      -              MANGLE_ENABLED=Yes
      -
      - Three different configurations are covered:
      - +
      +         NAT_ENABLED=Yes
      +               MANGLE_ENABLED=Yes
      +
      + Three different configurations are covered:
      +
        -
      1. Squid running on the -Firewall.
        2. -
      2. Squid running in the local -network
        3. -
      3. Squid running in the DMZ
        4. - +
      4. Squid running on the + Firewall.
        5. +
      5. Squid running in the +local network
        6. +
      6. Squid running in the DMZ
        7. +
      - +

      Squid Running on the Firewall

      - You want to redirect all local www connection requests EXCEPT - those to your own - http server (206.124.146.177) - to a Squid transparent - proxy running on the firewall and listening on port 3128. Squid - will of course require access to remote web servers.
      -
      - In /etc/shorewall/rules:
      -
      + You want to redirect all local www connection requests EXCEPT + those to your own + http server (206.124.146.177) + to a Squid transparent + proxy running on the firewall and listening on port 3128. Squid + will of course require access to remote web servers.
      +
      + In /etc/shorewall/rules:
      +
      + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      REDIRECTloc3128tcpwww -
      +       		!206.124.146.177
      ACCEPTfwnettcpwww
      +
      +
      +
      +
      + +

      Squid Running in the local network

      + You want to redirect all local www connection requests to a Squid + transparent proxy + running in your local zone at 192.168.1.3 and listening on port 3128. +Your local interface is eth1. There may also be a web server running on 192.168.1.3. +It is assumed that web access is already enabled from the local zone to the +internet.
      + +

      WARNING: This setup may conflict with + other aspects of your gateway including but not limited to traffic shaping + and route redirection. For that reason, I don't recommend it.
      +

      + +
        +
      • On your firewall system, issue the following command
        +
        • + +
      + +
      + 
      echo 202 www.out >> /etc/iproute2/rt_tables
      +
      + +
        +
      • In /etc/shorewall/init, put:
        +
        • + +
      + +
      + 
      if [ -z "`ip rule list | grep www.out`" ] ; then
      	ip rule add fwmark 202 table www.out
      	ip route add default via 192.168.1.3 dev eth1 table www.out
      	ip route flush cache
      	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
      fi
      +
      + +
        +
      • In /etc/shorewall/rules:
        +
        + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDEST PROTODEST
        + PORT(S)        		SOURCE
        + PORT(S)        		ORIGINAL
        + DEST
        ACCEPT
        +         		locloc
        +         		tcpwww
        +
        +
        +
        +
        • +
      • Alternativfely, you can have the following policy:
        +
        + + + + + + + + + + + + + + + + + + + +
        SOURCE
        +         		DESTINATION
        +         		POLICY
        +         		LOG LEVEL
        +         		BURST PARAMETERS
        +
        loc
        +         		loc
        +         		ACCEPT
        +
        +
        +
        +
        +
        • +
      • In /etc/shorewall/start add:
        +
        • + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
      REDIRECTloc3128tcpwww -
      -       		!206.124.146.177
      ACCEPTfwnettcpwww
      -
      -
      -
      + 
      iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
      -

      Squid Running in the local network

      - You want to redirect all local www connection requests to a Squid - transparent proxy -running in your local zone at 192.168.1.3 and listening on port 3128. -Your local interface is eth1. There may also be a web server running on -192.168.1.3. It is assumed that web access is already enabled from the local -zone to the internet.
      - -

      WARNING: This setup may conflict with - other aspects of your gateway including but not limited to traffic shaping - and route redirection. For that reason, I don't recommend it.
      -

      +
        +
      • On 192.168.1.3, arrange for the following command to be executed + after networking has come up
        + + 
        iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128
        +
        • -
          -
        • On your firewall system, issue the following command
          -
          • -
        -
        - 
        echo 202 www.out >> /etc/iproute2/rt_tables
        -
        - -
          -
        • In /etc/shorewall/init, put:
          -
          • - -
        - -
        - 
        if [ -z "`ip rule list | grep www.out`" ] ; then
        	ip rule add fwmark 202 table www.out
        	ip route add default via 192.168.1.3 dev eth1 table www.out
        	ip route flush cache
        	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
        fi
        -
        - -
          -
        • In /etc/shorewall/rules:
          -
          +
          If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command above:
          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 
          iptables-save > /etc/sysconfig/iptables
          chkconfig --level 35 iptables start
          + + +
          + +

          Squid Running in the DMZ (This is what I do)

          + You have a single Linux system in your DMZ with IP address 192.0.2.177. + You want to run both a web server and Squid on that system. Your DMZ interface + is eth1 and your local interface is eth2.
          + +
            +
          • On your firewall system, issue the following command
            +
            • + +
          + +
          + 
          echo 202 www.out >> /etc/iproute2/rt_tables
          +
          + +
            +
          • In /etc/shorewall/init, put:
            +
            • + +
          + +
          + 
          if [ -z "`ip rule list | grep www.out`" ] ; then
          	ip rule add fwmark 202 table www.out
          	ip route add default via 192.0.2.177 dev eth1 table www.out
          	ip route flush cache
          fi
          +
          + +
            +
          •  Do one of the following:
            +
            +A) In /etc/shorewall/start add
            +
            • + +
          + +
          + 
          	iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
          +
          + +
          B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf +and add the following entry in /etc/shorewall/tcrules:
          +
          +
          +
          +
          ACTIONSOURCEDEST PROTODEST
          - PORT(S)          		SOURCE
          - PORT(S)          		ORIGINAL
          - DEST
          ACCEPT
          -           		locloc
          -           		tcpwww
          -
          -
          + + + + + + + + + + + + + + + + + +
          MARK
          +           		SOURCE
          +           		DESTINATION
          +           		PROTOCOL
          +           		PORT
          +           		CLIENT PORT
          +
          202
          +           		eth2
          +           		0.0.0.0/0
          +           		tcp
          +           		80
          +           		-
          +
          -
          -
          • -
        • Alternativfely, you can have the following policy:
          -
          - - + +C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
          + +
          +
          +
          - - - - - + + + + + + - - - - - +
          SOURCE
          -           		DESTINATION
          -           		POLICY
          -           		LOG LEVEL
          -           		BURST PARAMETERS
          -           		MARK
          +           		SOURCE
          +           		DESTINATION
          +           		PROTOCOL
          +           		PORT
          +           		CLIENT PORT
          +
          loc
          +           		202:P
          		loc
          +           		eth2
          		ACCEPT
          +           		0.0.0.0/0

          +           		tcp

          +           		80
          +           		-
          -
          -
          • -
        • In /etc/shorewall/start add:
          -
          • - -
        - -
        - 
        iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
        - +
        +
          -
        • On 192.168.1.3, arrange for the following command to be executed -after networking has come up
          - - 
          iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128
          -
          • +
        • In /etc/shorewall/rules, you will need:
        - -
        If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
        -
        -
        - - 
        iptables-save > /etc/sysconfig/iptables
        chkconfig --level 35 iptables start
        -
        - -
        - -

        Squid Running in the DMZ (This is what I do)

        - You have a single Linux system in your DMZ with IP address 192.0.2.177. - You want to run both a web server and Squid on that system. Your DMZ interface - is eth1 and your local interface is eth2.
        - -
          -
        • On your firewall system, issue the following command
          -
          • - -
        - -
        - 
        echo 202 www.out >> /etc/iproute2/rt_tables
        -
        - -
          -
        • In /etc/shorewall/init, put:
          -
          • - -
        - -
        - 
        if [ -z "`ip rule list | grep www.out`" ] ; then
        	ip rule add fwmark 202 table www.out
        	ip route add default via 192.0.2.177 dev eth1 table www.out
        	ip route flush cache
        fi
        -
        - -
          -
        •  In /etc/shorewall/start add:
          -
          • - -
        - -
        - 
        iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
        -
        - -
          -
        • In /etc/shorewall/rules, you will need:
          • - -
        - -
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
        ACTION
        -         		SOURCE
        -         		DEST
        -         		PROTO
        -         		DEST
        - PORT(S)
        -         		CLIENT
        - PORT(2)
        -         		ORIGINAL
        - DEST
        -
        ACCEPT
        -         		dmz
        -         		net
        -         		tcp
        -         		80
        -
        -
        -
        ACTION
        +         		SOURCE
        +         		DEST
        +         		PROTO
        +         		DEST
        + PORT(S)
        +         		CLIENT
        + PORT(2)
        +         		ORIGINAL
        + DEST
        +
        ACCEPT
        +         		dmz
        +         		net
        +         		tcp
        +         		80
        +
        +
        +
        -
        -
        - -
          -
        • On 192.0.2.177 (your Web/Squid server), arrange for the following - command to be executed after networking has come up
          - - 
          iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
          -
          • - -
        - -
        If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
        +
        - -
        -
        + +
          +
        • On 192.0.2.177 (your Web/Squid server), arrange for the following + command to be executed after networking has come up
          + + 
          iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
          +
          • +
        + +
        If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command above:
        +
        + +
        +
        + 
        iptables-save > /etc/sysconfig/iptables
        chkconfig --level 35 iptables start
        -
        - +
        +
        - -

        Updated 1/10/2003 - Tom Eastep -

        + +

        Updated 1/23/2003 - Tom Eastep +

        - Copyright © 2003 Thomas M. Eastep.
        -
        -
        -
        +
        +
        +
        +

        diff --git a/STABLE/documentation/Shorewall_index_frame.htm b/STABLE/documentation/Shorewall_index_frame.htm index 14531ec23..1c40f74ab 100644 --- a/STABLE/documentation/Shorewall_index_frame.htm +++ b/STABLE/documentation/Shorewall_index_frame.htm @@ -2,149 +2,166 @@ - + - + - + - + Shorewall Index - - + + - + - - - + + - - - + + + - - - + + + + + + +
        +
        - + +

        Shorewall

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

        Quick Search
        -

        - -
        - -

        Extended Search

        - + + +

        Extended Search

        +

        Copyright © 2001, 2002 Thomas M. Eastep.

        - + size="2">2001-2003 Thomas M. Eastep.

        +

        -
        -
        -

        -
        +
        +
        +

        +
        +
        +
        +
        +
        +

        -
        -
        -
        - +
        +
        diff --git a/STABLE/documentation/Shorewall_sfindex_frame.htm b/STABLE/documentation/Shorewall_sfindex_frame.htm index 7b454b747..37404fe88 100644 --- a/STABLE/documentation/Shorewall_sfindex_frame.htm +++ b/STABLE/documentation/Shorewall_sfindex_frame.htm @@ -2,149 +2,166 @@ - + - + - + - + Shorewall Index - - + + + - + - - - + + - - - + + + - - - -
        +
        - +

        Shorewall

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

      Quick Search
      -

      - - - -

      Extended Search

      - + + +

      Extended Search

      +

      Copyright © 2001, 2002 Thomas M. Eastep.

      - + size="2">2001-2003 Thomas M. Eastep.

      +


      -

      -
      -
      +

      +
      +
      +
      +
      +
      +
      +
      +

      -
      -

      - +
      diff --git a/STABLE/documentation/blacklisting_support.htm b/STABLE/documentation/blacklisting_support.htm index 8999e2eb9..8a36ff001 100644 --- a/STABLE/documentation/blacklisting_support.htm +++ b/STABLE/documentation/blacklisting_support.htm @@ -1,95 +1,99 @@ - + - + - + - + Blacklisting Support - + - - - + + - - - + + + +
      +

      Blacklisting Support

      -
      - +

      Shorewall supports two different forms of blacklisting; static and dynamic.

      - +

      Static Blacklisting

      - -

      Shorewall static blacklisting support has the following configuration parameters:

      - + +

      Shorewall static blacklisting support has the following configuration +parameters:

      +
        -
      • You specify whether you want packets from blacklisted hosts dropped -or rejected using the BLACKLIST_DISPOSITION +
      • You specify whether you want packets from blacklisted hosts dropped + or rejected using the BLACKLIST_DISPOSITION setting in /etc/shorewall/shorewall.conf
        • -
      • You specify whether you want packets from blacklisted hosts logged -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. Beginning -with Shorewall version 1.3.8, you may also specify PROTOCOL and Port numbers/Service -names in the blacklist file.
        -
        • -
      • You specify the interfaces whose incoming packets you want checked -against the blacklist using the "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. Beginning + with Shorewall version 1.3.8, you may also specify PROTOCOL and Port numbers/Service + names in the blacklist file.
        +
        • +
      • You specify the interfaces whose incoming packets you want checked + against the blacklist using the "blacklist" option in /etc/shorewall/interfaces.
        • -
      • The black list is refreshed from /etc/shorewall/blacklist by the +
      • The black list is refreshed from /etc/shorewall/blacklist by the "shorewall refresh" command.
        • - +
      - +

      Dynamic Blacklisting

      - -

      Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting - doesn't use any configuration parameters but is rather controlled using -/sbin/shorewall commands:

      - + +

      Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting + doesn't use any configuration parameters but is rather controlled using + /sbin/shorewall commands:

      +
        -
      • drop <ip address list> - causes packets from the listed -IP addresses to be silently dropped by the firewall.
        • -
      • reject <ip address list> - causes packets from the listed -IP addresses to be rejected by the firewall.
        • -
      • allow <ip address list> - re-enables receipt of packets -from hosts previously blacklisted by a deny or reject command.
        • -
      • save - save the dynamic blacklisting configuration so that it will -be automatically restored the next time that the firewall is restarted.
        • -
      • show dynamic - displays the dynamic blacklisting configuration.
        • - +
      • drop <ip address list> - causes packets from the listed + IP addresses to be silently dropped by the firewall.
        • +
      • reject <ip address list> - causes packets from the +listed IP addresses to be rejected by the firewall.
        • +
      • allow <ip address list> - re-enables receipt of packets + from hosts previously blacklisted by a deny or reject command.
        • +
      • save - save the dynamic blacklisting configuration so that it will + be automatically restored the next time that the firewall is restarted.
        • +
      • show dynamic - displays the dynamic blacklisting configuration.
        • +
      - +Dynamic blacklisting is not dependent on the "blacklist" option in +/etc/shorewall/interfaces.
      +

      Example 1:

      - -
           shorewall drop 192.0.2.124 192.0.2.125
      - + +
           shorewall drop 192.0.2.124 192.0.2.125
      +

          Drops packets from hosts 192.0.2.124 and 192.0.2.125

      - +

      Example 2:

      - -
           shorewall allow 192.0.2.125
      - + +
           shorewall allow 192.0.2.125
      +

          Reenables access from 192.0.2.125.

      - -

      Last updated 10/7/2002 - Tom Eastep

      - -

      Copyright - © 2002 Thomas M. Eastep.

      -
      + +

      Last updated 2/7/2003 - Tom Eastep

      + +

      Copyright + © 2002, 2003 Thomas M. Eastep.

      +
      +

      diff --git a/STABLE/documentation/configuration_file_basics.htm b/STABLE/documentation/configuration_file_basics.htm index fd526e0e4..2e6379b18 100644 --- a/STABLE/documentation/configuration_file_basics.htm +++ b/STABLE/documentation/configuration_file_basics.htm @@ -1,339 +1,344 @@ - + - + - + - + Configuration File Basics - + - - - + + - - - -
      - +
      + +

      Configuration Files

      -
      - -

      Warning: If you copy or edit your - configuration files on a system running Microsoft Windows, you must - run them through dos2unix - before you use them with Shorewall.

      - -

      Files

      - -

      Shorewall's configuration files are in the directory /etc/shorewall.

      - -
        -
      • /etc/shorewall/shorewall.conf - used to set several - firewall parameters.
        • -
      • /etc/shorewall/params - use this file to set shell - variables that you will expand in other files.
        • -
      • /etc/shorewall/zones - partition the firewall's - view of the world into zones.
        • -
      • /etc/shorewall/policy - establishes firewall high-level - policy.
        • -
      • /etc/shorewall/interfaces - describes the interfaces - on the firewall system.
        • -
      • /etc/shorewall/hosts - allows defining zones in - terms of individual hosts and subnetworks.
        • -
      • /etc/shorewall/masq - directs the firewall where - to use many-to-one (dynamic) Network Address Translation (a.k.a. - Masquerading) and Source Network Address Translation (SNAT).
        • -
      • /etc/shorewall/modules - directs the firewall -to load kernel modules.
        • -
      • /etc/shorewall/rules - defines rules that are -exceptions to the overall policies established in /etc/shorewall/policy.
        • -
      • /etc/shorewall/nat - defines static NAT rules.
        • -
      • /etc/shorewall/proxyarp - defines use of Proxy -ARP.
        • -
      • /etc/shorewall/routestopped (Shorewall 1.3.4 and - later) - defines hosts accessible when Shorewall is stopped.
        • -
      • /etc/shorewall/tcrules - defines marking of packets - for later use by traffic control/shaping or policy routing.
        • -
      • /etc/shorewall/tos - defines rules for setting -the TOS field in packet headers.
        • -
      • /etc/shorewall/tunnels - defines IPSEC, GRE and - IPIP tunnels with end-points on the firewall system.
        • -
      • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC - addresses.
        • -
      • /etc/shorewall/init - commands that you wish to execute at the beginning - of a "shorewall start" or "shorewall restart".
        • -
      • /etc/shorewall/start - commands that you wish to execute at the completion - of a "shorewall start" or "shorewall restart"
        • -
      • /etc/shorewall/stop - commands that you wish to execute at the beginning - of a "shorewall stop".
        • -
      • /etc/shorewall/stopped - commands that you wish to execute at the -completion of a "shorewall stop".
        -
        • - -
      - -

      Comments

      - -

      You may place comments in configuration files by making the first non-whitespace - character a pound sign ("#"). You may also place comments at -the end of any line, again by delimiting the comment from the rest -of the line with a pound sign.

      - -

      Examples:

      - -
      # This is a comment
      - -
      ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
      - -

      Line Continuation

      - -

      You may continue lines in the configuration files using the usual backslash - ("\") followed immediately by a new line character.

      - -

      Example:

      - -
      ACCEPT	net	fw	tcp \
      smtp,www,pop3,imap  #Services running on the firewall
      - -

      Using DNS Names

      - -

      - -

      WARNING: I personally recommend strongly against - using DNS names in Shorewall configuration files. If you use DNS names - and you are called out of bed at 2:00AM because Shorewall won't start - as a result of DNS problems then don't say that you were not forewarned. -
      -

      - -

          -Tom
      -

      - -

      Beginning with Shorwall 1.3.9, Host addresses in Shorewall - configuration files may be specified as either IP addresses or DNS - Names.
      -
      - DNS names in iptables rules aren't nearly as useful as they - first appear. When a DNS name appears in a rule, the iptables utility - resolves the name to one or more IP addresses and inserts those addresses - into the rule. So changes in the DNS->IP address relationship that - occur after the firewall has started have absolutely no effect on the - firewall's ruleset.

      - -

      If your firewall rules include DNS names then:

      - -
        -
      • If your /etc/resolv.conf is wrong then your firewall -won't start.
        • -
      • If your /etc/nsswitch.conf is wrong then your firewall - won't start.
        • -
      • If your Name Server(s) is(are) down then your firewall - won't start.
        • -
      • If your startup scripts try to start your firewall before - starting your DNS server then your firewall won't start.
        -
        • -
      • Factors totally outside your control (your ISP's router - is down for example), can prevent your firewall from starting.
        • -
      • You must bring up your network interfaces prior to starting - your firewall.
        -
        • - -
      - -

      Each DNS name much be fully qualified and include a minumum - of two periods (although one may be trailing). This restriction is -imposed by Shorewall to insure backward compatibility with existing -configuration files.
      -
      - Examples of valid DNS names:
      -

      - -
        -
      • mail.shorewall.net
        • -
      • shorewall.net. (note the trailing period).
        • - -
      - Examples of invalid DNS names:
      - -
        -
      • mail (not fully qualified)
        • -
      • shorewall.net (only one period)
        • - -
      - DNS names may not be used as:
      - -
        -
      • The server address in a DNAT rule (/etc/shorewall/rules - file)
        • -
      • In the ADDRESS column of an entry in /etc/shorewall/masq.
        • -
      • In the /etc/shorewall/nat file.
        • - -
      - These restrictions are not imposed by Shorewall simply for -your inconvenience but are rather limitations of iptables.
      - -

      Complementing an Address or Subnet

      - -

      Where specifying an IP address, a subnet or an interface, you can - precede the item with "!" to specify the complement of the item. For - example, !192.168.1.4 means "any host but 192.168.1.4". There must -be no white space following the "!".

      - -

      Comma-separated Lists

      - -

      Comma-separated lists are allowed in a number of contexts within the - configuration files. A comma separated list:

      - -
        -
      • Must not have any embedded white space.
        - Valid: routestopped,dhcp,norfc1918
        - Invalid: routestopped,     dhcp,     norfc1818
        • -
      • If you use line continuation to break a comma-separated - list, the continuation line(s) must begin in column 1 (or -there would be embedded white space)
        • -
      • Entries in a comma-separated list may appear in - any order.
        • - -
      - -

      Port Numbers/Service Names

      - -

      Unless otherwise specified, when giving a port number you can use - either an integer or a service name from /etc/services.

      - -

      Port Ranges

      - -

      If you need to specify a range of ports, the proper syntax is <low - port number>:<high port number>. For example, - if you want to forward the range of tcp ports 4000 through 4100 to -local host 192.168.1.3, the entry in /etc/shorewall/rules is:
      -

      - -
           DNAT	net	loc:192.168.1.3	tcp	4000:4100
      - -

      Using Shell Variables

      - -

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

      - -

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

      - -

      Example:

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


      - Example (/etc/shorewall/interfaces record):

      - - -
      - - 
      net $NET_IF $NET_BCAST $NET_OPTIONS
      -
      -       - -

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

      - - -
      + + + +

      Warning: If you copy or edit your + configuration files on a system running Microsoft Windows, you must + run them through dos2unix + before you use them with Shorewall.

      + +

      Files

      + +

      Shorewall's configuration files are in the directory /etc/shorewall.

      + +
        +
      • /etc/shorewall/shorewall.conf - used to set several + firewall parameters.
        • +
      • /etc/shorewall/params - use this file to set +shell variables that you will expand in other files.
        • +
      • /etc/shorewall/zones - partition the firewall's + view of the world into zones.
        • +
      • /etc/shorewall/policy - establishes firewall +high-level policy.
        • +
      • /etc/shorewall/interfaces - describes the interfaces + on the firewall system.
        • +
      • /etc/shorewall/hosts - allows defining zones +in terms of individual hosts and subnetworks.
        • +
      • /etc/shorewall/masq - directs the firewall where + to use many-to-one (dynamic) Network Address Translation +(a.k.a. Masquerading) and Source Network Address Translation +(SNAT).
        • +
      • /etc/shorewall/modules - directs the firewall +to load kernel modules.
        • +
      • /etc/shorewall/rules - defines rules that are +exceptions to the overall policies established in /etc/shorewall/policy.
        • +
      • /etc/shorewall/nat - defines static NAT rules.
        • +
      • /etc/shorewall/proxyarp - defines use of Proxy + ARP.
        • +
      • /etc/shorewall/routestopped (Shorewall 1.3.4 +and later) - defines hosts accessible when Shorewall is stopped.
        • +
      • /etc/shorewall/tcrules - defines marking of packets + for later use by traffic control/shaping or policy routing.
        • +
      • /etc/shorewall/tos - defines rules for setting + the TOS field in packet headers.
        • +
      • /etc/shorewall/tunnels - defines IPSEC, GRE and + IPIP tunnels with end-points on the firewall system.
        • +
      • /etc/shorewall/blacklist - lists blacklisted +IP/subnet/MAC addresses.
        • +
      • /etc/shorewall/init - commands that you wish to execute at the beginning + of a "shorewall start" or "shorewall restart".
        • +
      • /etc/shorewall/start - commands that you wish to execute at the +completion of a "shorewall start" or "shorewall restart"
        • +
      • /etc/shorewall/stop - commands that you wish to execute at the beginning + of a "shorewall stop".
        • +
      • /etc/shorewall/stopped - commands that you wish to execute at the + completion of a "shorewall stop".
        +
        • + +
      + +

      Comments

      + +

      You may place comments in configuration files by making the first non-whitespace + character a pound sign ("#"). You may also place comments at + the end of any line, again by delimiting the comment from the +rest of the line with a pound sign.

      + +

      Examples:

      + +
      # This is a comment
      + +
      ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
      + +

      Line Continuation

      + +

      You may continue lines in the configuration files using the usual backslash + ("\") followed immediately by a new line character.

      + +

      Example:

      + +
      ACCEPT	net	fw	tcp \
      smtp,www,pop3,imap  #Services running on the firewall
      + +

      Using DNS Names

      + +

      + +

      WARNING: I personally recommend strongly against + using DNS names in Shorewall configuration files. If you use DNS +names and you are called out of bed at 2:00AM because Shorewall won't +start as a result of DNS problems then don't say that you were not forewarned. +
      +

      + +

          -Tom
      +

      + +

      Beginning with Shorwall 1.3.9, Host addresses in Shorewall + configuration files may be specified as either IP addresses or DNS + Names.
      +
      + DNS names in iptables rules aren't nearly as useful as they + first appear. When a DNS name appears in a rule, the iptables utility + resolves the name to one or more IP addresses and inserts those addresses + into the rule. So changes in the DNS->IP address relationship that + occur after the firewall has started have absolutely no effect on the + firewall's ruleset.

      + +

      If your firewall rules include DNS names then:

      + +
        +
      • If your /etc/resolv.conf is wrong then your firewall +won't start.
        • +
      • If your /etc/nsswitch.conf is wrong then your firewall + won't start.
        • +
      • If your Name Server(s) is(are) down then your firewall + won't start.
        • +
      • If your startup scripts try to start your firewall before + starting your DNS server then your firewall won't start.
        +
        • +
      • Factors totally outside your control (your ISP's router + is down for example), can prevent your firewall from starting.
        • +
      • You must bring up your network interfaces prior to starting + your firewall.
        +
        • + +
      + +

      Each DNS name much be fully qualified and include a minumum + of two periods (although one may be trailing). This restriction is +imposed by Shorewall to insure backward compatibility with existing +configuration files.
      +
      + Examples of valid DNS names:
      +

      + +
        +
      • mail.shorewall.net
        • +
      • shorewall.net. (note the trailing period).
        • + +
      + Examples of invalid DNS names:
      + +
        +
      • mail (not fully qualified)
        • +
      • shorewall.net (only one period)
        • + +
      + DNS names may not be used as:
      + +
        +
      • The server address in a DNAT rule (/etc/shorewall/rules + file)
        • +
      • In the ADDRESS column of an entry in /etc/shorewall/masq.
        • +
      • In the /etc/shorewall/nat file.
        • + +
      + These restrictions are not imposed by Shorewall simply for + your inconvenience but are rather limitations of iptables.
      + +

      Complementing an Address or Subnet

      + +

      Where specifying an IP address, a subnet or an interface, you can + precede the item with "!" to specify the complement of the item. For + example, !192.168.1.4 means "any host but 192.168.1.4". There must be +no white space following the "!".

      + +

      Comma-separated Lists

      + +

      Comma-separated lists are allowed in a number of contexts within the + configuration files. A comma separated list:

      + +
        +
      • Must not have any embedded white space.
        + Valid: routestopped,dhcp,norfc1918
        + Invalid: routestopped,     dhcp,     norfc1818
        • +
      • If you use line continuation to break a comma-separated + list, the continuation line(s) must begin in column 1 (or +there would be embedded white space)
        • +
      • Entries in a comma-separated list may appear +in any order.
        • + +
      + +

      Port Numbers/Service Names

      + +

      Unless otherwise specified, when giving a port number you can use + either an integer or a service name from /etc/services.

      + +

      Port Ranges

      + +

      If you need to specify a range of ports, the proper syntax is <low + port number>:<high port number>. For example, + if you want to forward the range of tcp ports 4000 through 4100 to local + host 192.168.1.3, the entry in /etc/shorewall/rules is:
      +

      +
           DNAT	net	loc:192.168.1.3	tcp	4000:4100
      +If you omit the low port number, a value of zero is assumed; if you omit +the high port number, a value of 65535 is assumed.
      + +

      Using Shell Variables

      + +

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

      + +

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

      + +

      Example:

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


      + Example (/etc/shorewall/interfaces record):

      + + +
      + + 
      net $NET_IF $NET_BCAST $NET_OPTIONS
      +
      +       + +

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

      + + +
      + 
      net eth0 130.252.100.255 noping,norfc1918
      -
      -       - -

      Variables may be used anywhere in the other configuration +

      +       + +

      Variables may be used anywhere in the other configuration files.

      - +

      Using MAC Addresses

      - -

      Media Access Control (MAC) addresses can be used to specify packet - source in several of the configuration files. To use this feature, - your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) + +

      Media Access Control (MAC) addresses can be used to specify packet + source in several of the configuration files. To use this feature, + your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) included.

      - -

      MAC addresses are 48 bits wide and each Ethernet Controller has a - unique MAC address.
      -
      - In GNU/Linux, MAC addresses are usually written as a -series of 6 hex numbers separated by colons. Example:
      -
      -      [root@gateway root]# ifconfig eth0
      -      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
      -      inet addr:206.124.146.176 Bcast:206.124.146.255 - Mask:255.255.255.0
      -      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      -      RX packets:2398102 errors:0 dropped:0 overruns:0 - frame:0
      -      TX packets:3044698 errors:0 dropped:0 overruns:0 - carrier:0
      -      collisions:30394 txqueuelen:100
      -      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 - (1582.8 Mb)
      -      Interrupt:11 Base address:0x1800
      -
      - Because Shorewall uses colons as a separator for address - fields, Shorewall requires MAC addresses to be written in another - way. In Shorewall, MAC addresses begin with a tilde ("~") and consist - of 6 hex numbers separated by hyphens. In Shorewall, the MAC address - in the example above would be written "~02-00-08-E3-FA-55".
      -

      - -

      Note: It is not necessary to use the special Shorewall notation + +

      MAC addresses are 48 bits wide and each Ethernet Controller has a + unique MAC address.
      +
      + In GNU/Linux, MAC addresses are usually written as +a series of 6 hex numbers separated by colons. Example:
      +
      +      [root@gateway root]# ifconfig eth0
      +      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
      +      inet addr:206.124.146.176 Bcast:206.124.146.255 + Mask:255.255.255.0
      +      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
      +      RX packets:2398102 errors:0 dropped:0 overruns:0 + frame:0
      +      TX packets:3044698 errors:0 dropped:0 overruns:0 + carrier:0
      +      collisions:30394 txqueuelen:100
      +      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 + (1582.8 Mb)
      +      Interrupt:11 Base address:0x1800
      +
      + Because Shorewall uses colons as a separator for address + fields, Shorewall requires MAC addresses to be written in another + way. In Shorewall, MAC addresses begin with a tilde ("~") and +consist of 6 hex numbers separated by hyphens. In Shorewall, the +MAC address in the example above would be written "~02-00-08-E3-FA-55".
      +

      + +

      Note: It is not necessary to use the special Shorewall notation in the /etc/shorewall/maclist file.
      -

      - +

      +

      Shorewall Configurations

      - -

      Shorewall allows you to have configuration directories other than /etc/shorewall. - The shorewall start -and restart commands allow you to specify an alternate configuration - directory and Shorewall will use the files in the alternate directory - rather than the corresponding files in /etc/shorewall. The alternate -directory need not contain a complete configuration; those files not -in the alternate directory will be read from /etc/shorewall.

      - -

      This facility permits you to easily create a test or temporary configuration + +

      Shorewall allows you to have configuration directories other than /etc/shorewall. + The shorewall start and + restart commands allow you to specify an alternate configuration + directory and Shorewall will use the files in the alternate directory + rather than the corresponding files in /etc/shorewall. The alternate directory + need not contain a complete configuration; those files not in the alternate + directory will be read from /etc/shorewall.

      + +

      This facility permits you to easily create a test or temporary configuration by:

      - +
        -
      1. copying the files that need modification from +
      2. copying the files that need modification from /etc/shorewall to a separate directory;
        3. -
      3. modify those files in the separate directory; +
      4. modify those files in the separate directory; and
        5. -
      5. specifying the separate directory in a shorewall - start or shorewall restart command (e.g., shorewall -c /etc/testconfig +
      6. specifying the separate directory in a shorewall + start or shorewall restart command (e.g., shorewall -c /etc/testconfig restart ).
        7. - +
      - -

      Updated 12/29/2002 - Tom Eastep -

      + +

      Updated 2/7/2003 - Tom Eastep +

      - -

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

      + +

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

      +



      diff --git a/STABLE/documentation/download.htm b/STABLE/documentation/download.htm index b003501cf..4b6be7b3e 100644 --- a/STABLE/documentation/download.htm +++ b/STABLE/documentation/download.htm @@ -1,392 +1,391 @@ - + - + - + - + Download - + - - - - - - -
      - -

      Shorewall Download

      -
      + + + +

      Shorewall Download

      + + + + + + +

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

      - -

      The entire set of Shorewall documentation is available in PDF format -at:

      - + href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide + for the configuration that most closely matches your own.
      +

      + +

      The entire set of Shorewall documentation is available in PDF format at:

      +

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

      - -

      The documentation in HTML format is included in the .rpm and in the -.tgz packages below.

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

      + +

      The documentation in HTML format is included in the .rpm and in the .tgz +packages below.

      +

      Once you've done that, download one of the modules:

      - + - -

      The documentation in HTML format is included in the .tgz and .rpm files + +

      The documentation in HTML format is included in the .tgz and .rpm files and there is an documentation .deb that also contains the documentation.

      - -

      Please verify the version that you have downloaded -- during the - release of a new version of Shorewall, the links below may - point to a newer or an older version than is shown below.

      - + +

      Please verify the version that you have downloaded -- during the + release of a new version of Shorewall, the links below may +point to a newer or an older version than is shown below.

      +
        -
      • RPM - "rpm -qip LATEST.rpm"
        • -
      • TARBALL - "tar -ztf LATEST.tgz" (the directory name - will contain the version)
        • -
      • LRP - "mkdir Shorewall.lrp; cd Shorewall.lrp; tar - -zxf <downloaded .lrp>; cat var/lib/lrpkg/shorwall.version" +
      • RPM - "rpm -qip LATEST.rpm"
        • +
      • TARBALL - "tar -ztf LATEST.tgz" (the directory name + will contain the version)
        • +
      • LRP - "mkdir Shorewall.lrp; cd Shorewall.lrp; tar + -zxf <downloaded .lrp>; cat var/lib/lrpkg/shorwall.version"
        • - +
      - +

      Once you have verified the version, check the errata to see -if there are updates that apply to the version that you have - downloaded.

      - -

      WARNING - YOU CAN NOT SIMPLY INSTALL -THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION - IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration + color="#ff0000"> errata to see +if there are updates that apply to the version that you have +downloaded.

      + +

      WARNING - YOU CAN NOT SIMPLY INSTALL +THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION +IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.

      - -

      Download Latest Version (1.3.13): Remember that updates - to the mirrors occur 1-12 hours after an update to the Washington State -site.

      - -
      + +

      Download Latest Version (1.3.14): Remember that updates + to the mirrors occur 1-12 hours after an update to the Washington +State site.

      + +
      - + + + + + + + - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
      SERVER LOCATIONDOMAINHTTPFTP
      SERVER LOCATIONDOMAINHTTPFTP
      SourceForge
      -       		sf.net
      -       		SourceForge
      +       		sf.net
      +       		Download
      -
      -
      Slovak RepublicShorewall.netDownload .rpm
      - Download - .tgz 
      - Download - .lrp
      - - Download.md5sums      		 Download - .rpm  
      - Download - .tgz 
      - Download - .rpm
      - - Download.md5sums
      Texas, USAInfohiiway.comDownload - .rpm
      - Download - .tgz 
      - Download - .lrp
      - - Download.md5sums      		 Download .rpm  
      - Download - .tgz 
      - Download - .lrp
      - - Download.md5sums
      Hamburg, GermanyShorewall.net Download - .rpm
      - Download - .tgz
      - Download - .lrp
      - - Download.md5sums      		 Download - .rpm  
      - Download - .tgz 
      - Download - .lrp
      - Download - .md5sums
      Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar Download - .rpm  
      - Download - .tgz 
      - - Download .lrp
      - Download - .md5sums      		 Download - .rpm  
      - Download - .tgz 
      - - Download .lrp
      - Download - .md5sums
      Paris, FranceShorewall.netDownload .rpm
      - Download -.tgz 
      - Download -.lrp
      - Download - .md5sums      		 Download - .rpm  
      - Download - .tgz 
      - Download - .lrp
      - Download - .md5sums
      Washington State, USA
      -       		Shorewall.net
      -       		Download .rpm
      - Download - .tgz 
      - Download - .lrp
      - Download - .md5sums
      -       		- Download .rpm 
      - Download - .tgz 
      - Download - .lrp
      - Download - .md5sums
      -
      +
      Slovak RepublicShorewall.netDownload .rpm
      + Download + .tgz 
      + Download + .lrp
      + + Download.md5sums      		 Download + .rpm  
      + Download + .tgz 
      + Download + .rpm
      + + Download.md5sums
      Texas, USAInfohiiway.comDownload + .rpm
      + Download + .tgz 
      + Download + .lrp
      + + Download.md5sums      		 Download .rpm  
      + Download + .tgz 
      + Download + .lrp
      + + Download.md5sums
      Hamburg, GermanyShorewall.net Download + .rpm
      + Download + .tgz
      + Download + .lrp
      + + Download.md5sums      		 Download + .rpm  
      + Download + .tgz 
      + Download + .lrp
      + Download + .md5sums
      Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar Download + .rpm  
      + Download + .tgz 
      + + Download .lrp
      + Download + .md5sums      		 Download + .rpm  
      + Download + .tgz 
      + + Download .lrp
      + Download + .md5sums
      Paris, FranceShorewall.netDownload .rpm
      + Download .tgz 
      + Download .lrp
      + Download + .md5sums      		 Download + .rpm  
      + Download + .tgz 
      + Download + .lrp
      + Download + .md5sums
      Washington State, USA
      +       		Shorewall.net
      +       		Download .rpm
      + Download + .tgz 
      + Download + .lrp
      + Download + .md5sums
      +       		+ Download .rpm 
      + Download + .tgz 
      + Download + .lrp
      + Download + .md5sums
      +
      -
      - +
      +

      Browse Download Sites:

      - -
      + +
      - - - - - - - - - - - + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
      SERVER LOCATIONDOMAINHTTPFTP
      SourceForge
      -       		sf.net +
      SERVER LOCATIONDOMAINHTTPFTP
      SourceForge
      +       		sf.netBrowseN/A
      Slovak RepublicShorewall.netBrowse Browse
      Texas, USAInfohiiway.comBrowseBrowse
      Hamburg, GermanyShorewall.netBrowseBrowse
      Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
      FranceShorewall.netBrowse Browse
      N/A
      Washington State, USAShorewall.netBrowseBrowseSlovak RepublicShorewall.netBrowse Browse
      Texas, USAInfohiiway.comBrowseBrowse
      Hamburg, GermanyShorewall.netBrowseBrowse
      Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
      FranceShorewall.netBrowse Browse
      Washington State, USAShorewall.netBrowseBrowse
      -
      - +
      +

      CVS:

      - -
      + +

      The CVS repository at - cvs.shorewall.net contains the latest snapshots of the each Shorewall - component. There's no guarantee that what you find there will work -at all.
      -

      -
      - -

      Last Updated 1/13/2003 - CVS repository +at cvs.shorewall.net contains the latest snapshots of the each + Shorewall component. There's no guarantee that what you find there +will work at all.
      +

      +
      + +

      Last Updated 2/7/2003 - Tom Eastep

      - +

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

      +

      +


      diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index d5228db74..5a2a445dd 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -1,240 +1,281 @@ - + + Shorewall 1.3 Errata - + - + + + - + - - - + + - - - + + + + +
      - +
      + +

      Shorewall Errata/Upgrade Issues

      -
      - +

      IMPORTANT

      - +
        -
      1. - +
      2. +

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

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

        +
        4. +
      4. +

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

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

        +
        6. +
      6. +

        If you are running a Shorewall version earlier -than 1.3.11, when the instructions say to install a corrected firewall -script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall - or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to overwrite - the existing file. DO NOT REMOVE OR RENAME THE OLD /etc/shorewall/firewall - or /var/lib/shorewall/firewall before you do that. /etc/shorewall/firewall - and /var/lib/shorewall/firewall are symbolic links that point - to the 'shorewall' file used by your system initialization scripts - to start Shorewall during boot. It is that file that must be overwritten - with the corrected script. Beginning with Shorewall 1.3.11, you -may rename the existing file before copying in the new file.

        -
        7. -
      7. + than 1.3.11, when the instructions say to install a corrected firewall + script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall + or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to +overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD +/etc/shorewall/firewall or /var/lib/shorewall/firewall before +you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall + are symbolic links that point to the 'shorewall' file used by +your system initialization scripts to start Shorewall during +boot. It is that file that must be overwritten with the corrected +script. Beginning with Shorewall 1.3.11, you may rename the existing file +before copying in the new file.

        +
        8. +
      8. +

        DO NOT INSTALL CORRECTED COMPONENTS - ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. For - example, do NOT install the 1.3.9a firewall script if you are running -1.3.7c.
        -

        -
        9. - + ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. +For example, do NOT install the 1.3.9a firewall script if you are running + 1.3.7c.
        +

        + +
      - + - -
      + +

      Problems in Version 1.3

      - -

      Version 1.3.12

      + +

      Version 1.3.13

      +
        -
      • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect is the -same as if RFC_1918_LOG_LEVEL=info had been specified. The problem is corrected -by this -firewall script which may be installed in /usr/lib/shorewall as described -above.
        +
      • The 'shorewall add' command produces an error message referring +to 'find_interfaces_by_maclist'.
        • +
      • The 'shorewall delete' command can leave behind undeleted rules.
        • +
      • The 'shorewall add' command can fail with "iptables: Index of insertion +too big".
        • +
      -

      Version 1.3.12 LRP

      + All three problems are corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
        -
      • The .lrp was missing the /etc/shorewall/routestopped file -- a new -lrp (shorwall-1.3.12a.lrp) has been released which corrects this problem.
        +
      • VLAN interface names of the form "ethn.m" (e.g., eth0.1) +are not supported in this version or in 1.3.12. If you need such support, +post on the users list and I can provide you with a patched version.
      - -

      Version 1.3.11a

      - + +

      Version 1.3.12

      +
        -
      • This - copy of /etc/shorewall/rfc1918 reflects the recent allocation of 82.0.0.0/8.
        +
      • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect is + the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem +is corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
        • +
      • VLAN interface names of the form "ethn.m" (e.g., eth0.1) + are not supported in this version or in 1.3.13. If you need such support, + post on the users list and I can provide you with a patched version.
        • - +
      - + +

      Version 1.3.12 LRP

      + +
        +
      • The .lrp was missing the /etc/shorewall/routestopped file -- a +new lrp (shorwall-1.3.12a.lrp) has been released which corrects this problem.
        +
        • + +
      + +

      Version 1.3.11a

      + + +

      Version 1.3.11

      - + - -

      Version 1.3.10

      - -
        -
      • If you experience problems connecting to a PPTP server running - on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, - this - version of the firewall script may help. Please report any cases where - installing this script in /usr/lib/shorewall/firewall solved your connection - problems. Beginning with version 1.3.10, it is safe to save the old version - of /usr/lib/shorewall/firewall before copying in the new one since /usr/lib/shorewall/firewall - is the real script now and not just a symbolic link to the real script.
        -
        • - -
      - -

      Version 1.3.9a

      - -
        -
      • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No - then the following message appears during "shorewall [re]start":
        • - + corrected script in /usr/lib/shorewall/firewall to correct this problem. + Thanks go to Roger Aich who analyzed this problem and provided a fix.
        +
        + This problem is corrected in version 1.3.11a.
        + +
      +

      Version 1.3.10

      + +
        +
      • If you experience problems connecting to a PPTP server running + on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, + this + version of the firewall script may help. Please report any cases +where installing this script in /usr/lib/shorewall/firewall solved your +connection problems. Beginning with version 1.3.10, it is safe to save +the old version of /usr/lib/shorewall/firewall before copying in the +new one since /usr/lib/shorewall/firewall is the real script now and +not just a symbolic link to the real script.
        +
        • + +
      + +

      Version 1.3.9a

      + +
        +
      • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No + then the following message appears during "shorewall [re]start":
        • + +
      + 
                recalculate_interfacess: command not found
      - +
      The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - corrects this problem.Copy the script to /usr/lib/shorewall/firewall as - described above.
      -
      - + corrects this problem.Copy the script to /usr/lib/shorewall/firewall + as described above.
      + +
      Alternatively, edit /usr/lob/shorewall/firewall and change the - single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' - to 'recalculate_interface'.
      -
      - + single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' + to 'recalculate_interface'.
      + + - +

      Version 1.3.9

      - TUNNELS Broken in 1.3.9!!! There is an updated firewall -script at TUNNELS Broken in 1.3.9!!!       There is an updated firewall + script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall as described above.
      -
      - Version 1.3.8 + -- copy that file to /usr/lib/shorewall/firewall as described above.
      +
      + Version 1.3.8
        -
      • Use of shell variables in the LOG LEVEL or SYNPARMS columns - of the policy file doesn't work.
        • -
      • A DNAT rule with the same original and new IP addresses - but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24 - tcp 25 - 10.1.1.1")
        -
        • - +
      • Use of shell variables in the LOG LEVEL or SYNPARMS + columns of the policy file doesn't work.
        • +
      • A DNAT rule with the same original and new IP addresses + but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24 + tcp 25 - 10.1.1.1")
        +
        • +
      - Installing this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects these problems. - + as described above corrects these +problems.

      Version 1.3.7b

      - +

      DNAT rules where the source zone is 'fw' ($FW) result in an error message. Installing this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this problem.

      - + as described above corrects this +problem.

      +

      Version 1.3.7a

      - +

      "shorewall refresh" is not creating the proper rule for FORWARDPING=Yes. Consequently, after "shorewall refresh", the firewall will not forward @@ -242,356 +283,372 @@ script at this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this problem.

      - + as described above corrects this +problem.

      +

      Version <= 1.3.7a

      - +

      If "norfc1918" and "dhcp" are both specified as options on a given interface then RFC 1918 checking is occurring before DHCP checking. This means that if a DHCP client broadcasts using an RFC 1918 source address, then the firewall will reject the broadcast (usually logging it). This - has two problems:

      - + has two problems:

      +
        -
      1. If the firewall is running - a DHCP server, the client won't be -able to obtain an IP address lease from -that server.
        2. -
      2. With this order of checking, - the "dhcp" option cannot be used as - a noise-reduction measure where there - are both dynamic and static clients -on a LAN segment.
        3. - +
      3. If the firewall is +running a DHCP server, the client +won't be able to obtain an IP address + lease from that server.
        4. +
      4. With this order of +checking, the "dhcp" option cannot +be used as a noise-reduction measure +where there are both dynamic and static + clients on a LAN segment.
        5. +
      - +

      This version of the 1.3.7a firewall script - corrects the problem. It must be installed - in /var/lib/shorewall as described -above.

      - + corrects the problem. It must be installed + in /var/lib/shorewall as described + above.

      +

      Version 1.3.7

      - +

      Version 1.3.7 dead on arrival -- please use version 1.3.7a and check your version against these md5sums -- if there's a difference, please download again.

      - + 
      	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
      	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
      	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
      - +

      In other words, type "md5sum <whatever package you downloaded> - and compare the result with what you see above.

      - + and compare the result with what you see above.

      +

      I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the - .7 version in each sequence from now on.

      - + .7 version in each sequence from now on.

      +

      Version 1.3.6

      - +
        -
      • - +
      • + +

        If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf, - an error occurs when the firewall script attempts to add - an SNAT alias.

        -
        • -
      • - + an error occurs when the firewall script attempts to +add an SNAT alias.

        +
        • +
      • +

        The logunclean and dropunclean options cause errors during startup when Shorewall is run with iptables - 1.2.7.

        -
        • - + 1.2.7.

        + +
      - +

      These problems are fixed in this correct firewall script which must be installed in /var/lib/shorewall/ as described above. These problems are also corrected in version 1.3.7.

      - +

      Two-interface Samples 1.3.6 (file two-interfaces.tgz)

      - +

      A line was inadvertently deleted from the "interfaces file" -- this line should be added back in if the version that you - downloaded is missing it:

      - + downloaded is missing it:

      +

      net    eth0    detect    routefilter,dhcp,norfc1918

      - +

      If you downloaded two-interfaces-a.tgz then the above line should already be in the file.

      - +

      Version 1.3.5-1.3.5b

      - +

      The new 'proxyarp' interface option doesn't work :-( This is fixed in this corrected firewall script which must be installed in /var/lib/shorewall/ as described above.

      - +

      Versions 1.3.4-1.3.5a

      - +

      Prior to version 1.3.4, host file entries such as the following were allowed:

      - -
      + +
      	adm	eth0:1.2.4.5,eth0:5.6.7.8
      -
      - -
      +
      + +

      That capability was lost in version 1.3.4 so that it is only - possible to  include a single host specification on each line. -This problem is corrected by this - modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall - as instructed above.

      -
      - -
      + modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall + as instructed above.

      +
      + +

      This problem is corrected in version 1.3.5b.

      -
      - +
      +

      Version 1.3.5

      - +

      REDIRECT rules are broken in this version. Install this corrected firewall script in /var/lib/pub/shorewall/firewall - as instructed above. This problem is corrected in version - 1.3.5a.

      - + as instructed above. This problem is corrected in version + 1.3.5a.

      +

      Version 1.3.n, n < 4

      - +

      The "shorewall start" and "shorewall restart" commands to not verify that the zones named in the /etc/shorewall/policy file have been previously defined in the /etc/shorewall/zones file. The "shorewall check" command does perform this verification so it's a good idea to run that command after you have made configuration - changes.

      - + changes.

      +

      Version 1.3.n, n < 3

      - +

      If you have upgraded from Shorewall 1.2 and after "Activating rules..." you see the message: "iptables: No chains/target/match - by that name" then you probably have an entry in /etc/shorewall/hosts - that specifies an interface that you didn't include in -/etc/shorewall/interfaces. To correct this problem, you - must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 and - later versions produce a clearer error message in this case.

      - + by that name" then you probably have an entry in /etc/shorewall/hosts + that specifies an interface that you didn't include in + /etc/shorewall/interfaces. To correct this problem, you + must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 +and later versions produce a clearer error message in this +case.

      +

      Version 1.3.2

      - +

      Until approximately 2130 GMT on 17 June 2002, the download sites contained an incorrect version of the .lrp file. That file can be identified by its size (56284 bytes). The correct version has a size of 38126 bytes.

      - +
        -
      • The code to detect a duplicate interface entry - in /etc/shorewall/interfaces contained a typo that prevented - it from working correctly.
        • -
      • "NAT_BEFORE_RULES=No" was broken; it behaved - just like "NAT_BEFORE_RULES=Yes".
        • - +
      • The code to detect a duplicate interface + entry in /etc/shorewall/interfaces contained a typo that prevented + it from working correctly.
        • +
      • "NAT_BEFORE_RULES=No" was broken; it behaved + just like "NAT_BEFORE_RULES=Yes".
        • +
      - +

      Both problems are corrected in this script which should be installed in /var/lib/shorewall - as described above.

      - + as described above.

      +
        -
      • - +
      • + +

        The IANA have just announced the allocation of subnet - 221.0.0.0/8. This updated rfc1918 file reflects that allocation.

        -
        • - + +
      - +

      Version 1.3.1

      - +
        -
      • TCP SYN packets may be double counted when - LIMIT:BURST is included in a CONTINUE or ACCEPT policy (i.e., - each packet is sent through the limit chain twice).
        • -
      • An unnecessary jump to the policy chain is -sometimes generated for a CONTINUE policy.
        • -
      • When an option is given for more than one -interface in /etc/shorewall/interfaces then depending -on the option, Shorewall may ignore all but the first +
      • TCP SYN packets may be double counted +when LIMIT:BURST is included in a CONTINUE or ACCEPT policy +(i.e., each packet is sent through the limit chain twice).
        • +
      • An unnecessary jump to the policy chain + is sometimes generated for a CONTINUE policy.
        • +
      • When an option is given for more than +one interface in /etc/shorewall/interfaces then depending + on the option, Shorewall may ignore all but the first appearence of the option. For example:
        -
        - net    eth0    dhcp
        - loc    eth1    dhcp
        -
        - Shorewall will ignore the 'dhcp' on eth1.
        • -
      • Update 17 June 2002 - The bug described in -the prior bullet affects the following options: dhcp, dropunclean, - logunclean, norfc1918, routefilter, multi, filterping and - noping. An additional bug has been found that affects only - the 'routestopped' option.
        -
        - Users who downloaded the corrected script prior - to 1850 GMT today should download and install the corrected - script again to ensure that this second problem is corrected.
        • - +
        + net    eth0    dhcp
        + loc    eth1    dhcp
        +
        + Shorewall will ignore the 'dhcp' on eth1. +
      • Update 17 June 2002 - The bug described + in the prior bullet affects the following options: dhcp, + dropunclean, logunclean, norfc1918, routefilter, multi, + filterping and noping. An additional bug has been found + that affects only the 'routestopped' option.
        +
        + Users who downloaded the corrected script +prior to 1850 GMT today should download and install +the corrected script again to ensure that this second +problem is corrected.
        • +
      - +

      These problems are corrected in this firewall script which should be installed in /etc/shorewall/firewall - as described above.

      - + as described above.

      +

      Version 1.3.0

      - + - -
      + +

      Upgrade Issues

      - +

      The upgrade issues have moved to a separate page.

      - -
      + +

      Problem with - iptables version 1.2.3

      - + iptables version 1.2.3       +
      - +

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

      - - -

      I have built a - corrected 1.2.3 rpm which you can download here  and I have also - built an -iptables-1.2.4 rpm which you can download here. If you are currently - running RedHat 7.1, you can install either of these RPMs - before you upgrade to RedHat 7.2.

      - -

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

      - - -

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

      - - -

      To install one of the above patches:

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

      Problems with kernels >= 2.4.18 - and RedHat iptables

      - -
      -

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

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

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

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

      +

      I have built a + corrected 1.2.3 rpm which you can download here  and I have +also built an +iptables-1.2.4 rpm which you can download here. If you are currently + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

      + + +

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

      + + +

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

      + + +

      To install one of the above patches:

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

      Problems with kernels >= 2.4.18 + and RedHat iptables

      + +
      +

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

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

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

      +
      + +

      Problems installing/upgrading - RPM on SuSE

      - + RPM on SuSE +

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

      - +

      Installing: rpm -ivh --nodeps <shorewall rpm>

      - +

      Upgrading: rpm -Uvh --nodeps <shorewall rpm>

      - +

      Problems with iptables version 1.2.7 and MULTIPORT=Yes

      - +

      The iptables 1.2.7 release of iptables has made an incompatible change to the syntax used to specify multiport match rules; as a consequence, if you install iptables 1.2.7 you must be running Shorewall 1.3.7a or later or:

      - + - +

      Problems with RH Kernel 2.4.18-10 and NAT
      -

      - /etc/shorewall/nat entries of the following form will result in -Shorewall being unable to start:
      -
      - + + /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 1/3/2003 - + 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 2/8/2003 - Tom Eastep

      - +

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

      +

      +
      +
      +
      +



      diff --git a/STABLE/documentation/mailing_list.htm b/STABLE/documentation/mailing_list.htm index c690a58da..8fd3276af 100644 --- a/STABLE/documentation/mailing_list.htm +++ b/STABLE/documentation/mailing_list.htm @@ -1,138 +1,153 @@ - + + - + + - + + - + + Shorewall Mailing Lists - + - + - - - + + - + - - - - +
      + Powered by Postfix    
      + + + + + +
      +
      - +

      Vexira Logo -

      + - -

      -

      - -


      -  

      -       		+ + +

       

      +       		+

      Shorewall Mailing Lists

      -       		-

      +

      		(Postfix Logo) - -
      - +
      + + +
      +

      - Powered by Postfix    
      -
      -
      - +

      Not getting List Mail? -- Check Here

      - -

      If you experience problems with any of these lists, please - let me know

      - + +

      If you experience problems with any of these lists, please + let me know

      +

      Not able to Post Mail to shorewall.net?

      - -

      You can report such problems by sending mail to tom dot eastep - at hp dot com.

      - + +

      You can report such problems by sending mail to tom dot eastep + at hp dot com.

      +

      A Word about SPAM Filters 

      - -

      Before subscribing please read my policy - about list traffic that bounces. Also please note that the mail server - at shorewall.net checks incoming mail:
      -

      - -
        -
      1. against Spamassassin - (including Vipul's Razor).
        -
        2. -
      2. to ensure that the sender address is fully qualified.
        3. -
      3. to verify that the sender's domain has an A or MX record -in DNS.
        4. -
      4. to ensure that the host name in the HELO/EHLO command is -a valid fully-qualified DNS name that resolves.
        5. - -
      - -

      Please post in plain text

      - A growing number of MTAs serving list subscribers are rejecting all -HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net -"for continuous abuse" because it has been my policy to allow HTML in list -posts!!
      -
      - I think that blocking all HTML is a Draconian way to control spam and - that the ultimate losers here are not the spammers but the list subscribers - whose MTAs are bouncing all shorewall.net mail. As one list subscriber wrote - to me privately "These e-mail admin's need to get a (explitive deleted) - life instead of trying to rid the planet of HTML based e-mail". Nevertheless, - to allow subscribers to receive list posts as must as possible, I have now - configured the list server at shorewall.net to strip all HTML from outgoing - posts. This means that HTML-only posts will be bounced by the list server.
      - -

      Note: The list server limits posts to 120kb.
      -

      + -

      Other Mail Delivery Problems

      - If you find that you are missing an occasional list post, your e-mail -admin may be blocking mail whose Received: headers contain the names -of certain ISPs. Again, I believe that such policies hurt more than they -help but I'm not prepared to go so far as to start stripping Received: -headers to circumvent those policies.
      - -

      Mailing Lists Archive Search

      +

      Before subscribing please read my policy + about list traffic that bounces. Also please note that the mail server + at shorewall.net checks incoming mail:
      +

      -
      +
        +
      1. against Spamassassin + (including Vipul's Razor).
        +
        2. +
      2. to ensure that the sender address is fully qualified.
        3. +
      3. to verify that the sender's domain has an A or MX record + in DNS.
        4. +
      4. to ensure that the host name in the HELO/EHLO command + is a valid fully-qualified DNS name that resolves.
        5. + +
      + +

      Please post in plain text

      + A growing number of MTAs serving list subscribers are rejecting +all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net + "for continuous abuse" because it has been my policy to allow HTML in list + posts!!
      +
      + I think that blocking all HTML is a Draconian way to control spam + and that the ultimate losers here are not the spammers but the list subscribers + whose MTAs are bouncing all shorewall.net mail. As one list subscriber + wrote to me privately "These e-mail admin's need to get a (explitive + deleted) life instead of trying to rid the planet of HTML based e-mail". + Nevertheless, to allow subscribers to receive list posts as must as possible, + I have now configured the list server at shorewall.net to strip all HTML + from outgoing posts. This means that HTML-only posts will be bounced by +the list server.
      + +

      Note: The list server limits posts to 120kb.
      +

      + +

      Other Mail Delivery Problems

      + If you find that you are missing an occasional list post, your e-mail + admin may be blocking mail whose Received: headers contain the names + of certain ISPs. Again, I believe that such policies hurt more than they + help but I'm not prepared to go so far as to start stripping Received: + headers to circumvent those policies.
      + +

      Mailing Lists Archive Search

      -

      Match: + + +

      Match: + - Format: + Format: + - Sort by: + Sort by: + - -
      - Search:

      - - -

      Please do not try to download the -entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply -won't stand the traffic. If I catch you, you will be blacklisted.
      -

      - + + +

      Please do not try to download the entire +Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't +stand the traffic. If I catch you, you will be blacklisted.
      +

      +

      Shorewall CA Certificate

      - If you want to trust X.509 certificates issued by Shoreline -Firewall (such as the one used on my web site), you may download and install my CA certificate - in your browser. If you don't wish to trust my certificates then you - can either use unencrypted access when subscribing to Shorewall mailing - lists or you can use secure access (SSL) and accept the server's certificate - when prompted by your browser.
      - + If you want to trust X.509 certificates issued by Shoreline + Firewall (such as the one used on my web site), you may download and install my CA certificate + in your browser. If you don't wish to trust my certificates then +you can either use unencrypted access when subscribing to Shorewall +mailing lists or you can use secure access (SSL) and accept the server's +certificate when prompted by your browser.
      +

      Shorewall Users Mailing List

      - -

      The Shorewall Users Mailing list provides a way for users - to get answers to questions and to report problems. Information of -general interest to the Shorewall user community is also posted to this -list.

      - -

      Before posting a problem report to this list, please see - the problem reporting guidelines.

      - -

      To subscribe to the mailing list, go to http://mail.shorewall.net/mailman/listinfo/shorewall-users - SSL: https//mail.shorewall.net/mailman/listinfo/shorewall-users

      - -

      To post to the list, post to shorewall-users@shorewall.net.

      - -

      The list archives are at http://mail.shorewall.net/pipermail/shorewall-users.

      - -

      Note that prior to 1/1/2002, the mailing list was hosted at -Sourceforge. The archives from that list -may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

      - -

      Shorewall Announce Mailing List

      - -

      This list is for announcements of general interest to the - Shorewall community. To subscribe, go to http://mail.shorewall.net/mailman/listinfo/shorewall-announce - SSL: https//mail.shorewall.net/mailman/listinfo/shorewall-announce.
      -
      - The list archives are at http://mail.shorewall.net/pipermail/shorewall-announce.

      - -

      Shorewall Development Mailing List

      - -

      The Shorewall Development Mailing list provides a forum for - the exchange of ideas about the future of Shorewall and for coordinating - ongoing Shorewall Development.

      - -

      To subscribe to the mailing list, go to http://mail.shorewall.net/mailman/listinfo/shorewall-devel - SSL: https//mail.shorewall.net/mailman/listinfo/shorewall-devel.
      - To post to the list, post to shorewall-devel@shorewall.net. 

      - -

      The list archives are at http://mail.shorewall.net/pipermail/shorewall-devel.

      - -

      How to Unsubscribe from one of - the Mailing Lists

      - -

      There seems to be near-universal confusion about unsubscribing - from Mailman-managed lists although Mailman 2.1 has attempted to make - this less confusing. To unsubscribe:

      - + +

      The Shorewall Users Mailing list provides a way for users + to get answers to questions and to report problems. Information +of general interest to the Shorewall user community is also posted +to this list.

      + +

      Before posting a problem report to this list, please see + the problem reporting + guidelines.

      + +

      To subscribe to the mailing list:
      +

      +
        -
      • - -

        Follow the same link above that you used to subscribe - to the list.

        -
        • -
      • - -

        Down at the bottom of that page is the following text: - " To unsubscribe from <list name>, get a password - reminder, or change your subscription options enter your subscription - email address:". Enter your email address in the box and click - on the "Unsubscribe or edit options" button.

        -
        • -
      • - -

        There will now be a box where you can enter your password - and click on "Unsubscribe"; if you have forgotten your password, there - is another button that will cause your password to be emailed to you.

        -
        • - +
      • Insecure: http://lists.shorewall.net/mailman/listinfo/shorewall-users
        • +
      • SSL: https//lists.shorewall.net/mailman/listinfo/shorewall-users
        • +
      - -
      + +

      To post to the list, post to shorewall-users@lists.shorewall.net.

      + +

      The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.

      + +

      Note that prior to 1/1/2002, the mailing list was hosted +at Sourceforge. The archives from that +list may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

      + +

      Shorewall Announce Mailing List

      + +

      This list is for announcements of general interest to the + Shorewall community. To subscribe:
      +

      + +

      + + + +


      + The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce.

      + +

      Shorewall Development Mailing List

      + +

      The Shorewall Development Mailing list provides a forum for + the exchange of ideas about the future of Shorewall and for coordinating + ongoing Shorewall Development.

      + +

      To subscribe to the mailing list:
      +

      + + + +

      To post to the list, post to shorewall-devel@lists.shorewall.net. 

      + +

      The list archives are at http://lists.shorewall.net/pipermail/shorewall-devel.

      + +

      How to Unsubscribe from one of + the Mailing Lists

      + +

      There seems to be near-universal confusion about unsubscribing + from Mailman-managed lists although Mailman 2.1 has attempted +to make this less confusing. To unsubscribe:

      + +
        +
      • + +

        Follow the same link above that you used to subscribe + to the list.

        +
        • +
      • + +

        Down at the bottom of that page is the following text: + " To unsubscribe from <list name>, get a password + reminder, or change your subscription options enter your subscription + email address:". Enter your email address in the box and click + on the "Unsubscribe or edit options" button.

        +
        • +
      • + +

        There will now be a box where you can enter your password + and click on "Unsubscribe"; if you have forgotten your password, + there is another button that will cause your password to be emailed + to you.

        +
        • + +
      + +

      Frustrated by having to Rebuild Mailman to use it with Postfix?

      - +

      Check out these instructions

      - -

      Last updated 12/31/2002 - Tom Eastep

      - -

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

      -
      -
      -
      -
      -
      + +

      Last updated 2/3/2003 - Tom Eastep

      + +

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


      diff --git a/STABLE/documentation/myfiles.htm b/STABLE/documentation/myfiles.htm index a05025c11..e43a34778 100644 --- a/STABLE/documentation/myfiles.htm +++ b/STABLE/documentation/myfiles.htm @@ -1,144 +1,146 @@ - + My Shorewall Configuration - + - - + + - + - - - + + - - - -
      - +
      +

      About My Network

      -
      + + -
      - -

      My Current Network

      + + -
      -

      Warning: I -use a combination of Static NAT and Proxy ARP, neither of which are relevant -to a simple configuration with a single public IP address. -If you have just a single public IP address, most of what you see here won't -apply to your setup so beware of copying parts of this configuration and -expecting them to work for you. They may or may not work in your setup.
      -

      -

      I have DSL service and have 5 static IP addresses (206.124.146.176-180). - My DSL "modem" (Fujitsu Speedport) - is connected to eth0. I have a local network connected to eth2 (subnet -192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). 

      - +
      + +

      My Current Network

      + +
      +

      Warning: I +use a combination of Static NAT and Proxy ARP, neither of which are relevant +to a simple configuration with a single public IP address. +If you have just a single public IP address, most of what you see here won't +apply to your setup so beware of copying parts of this configuration and expecting +them to work for you. What you copy may or may not work in your setup.
      +

      + +

      I have DSL service and have 5 static IP addresses (206.124.146.176-180). + My DSL "modem" (Fujitsu Speedport) + is connected to eth0. I have a local network connected to eth2 (subnet + 192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). 

      +

      I use:
      -

      - +

      +
        -
      • Static NAT for ursa (my XP System) - Internal address 192.168.1.5 - and external address 206.124.146.178.
        • -
      • Proxy ARP for wookie (my Linux System). This system has two +
      • Static NAT for ursa (my XP System) - Internal address 192.168.1.5 + and external address 206.124.146.178.
        • +
      • Proxy ARP for wookie (my Linux System). This system has two IP addresses: 192.168.1.3/24 and 206.124.146.179/24.
        • -
      • SNAT through the primary gateway address (206.124.146.176) -for  my Wife's system (tarry) and the Wireless Access Point (wap)
        • - +
      • SNAT through the primary gateway address (206.124.146.176) + for  my Wife's system (tarry) and the Wireless Access Point (wap)
        • +
      - +

      The firewall runs on a 128MB PII/233 with RH7.2 and Kernel 2.4.20-pre6.

      - -

      Wookie runs Samba and acts as the a WINS server.  Wookie is in its - own 'whitelist' zone called 'me'.

      - -

      My laptop (eastept1) is connected to eth3 using a cross-over cable. - It runs its own Sygate firewall software - and is managed by Proxy ARP. It connects to the local network through -the PopTop server running on my firewall.

      - -

      The single system in the DMZ (address 206.124.146.177) runs postfix, - Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP server - (Pure-ftpd). The system also runs fetchmail to fetch our email from -our old and current ISPs. That server is managed through Proxy ARP.

      - -

      The firewall system itself runs a DHCP server that serves the local - network.

      - + +

      Wookie runs Samba and acts as the a WINS server.  Wookie is in its + own 'whitelist' zone called 'me'.

      + +

      My laptop (eastept1) is connected to eth3 using a cross-over cable. + It runs its own Sygate firewall +software and is managed by Proxy ARP. It connects to the local network +through the PopTop server running on my firewall.

      + +

      The single system in the DMZ (address 206.124.146.177) runs postfix, + Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP +server (Pure-ftpd). The system also runs fetchmail to fetch our email +from our old and current ISPs. That server is managed through Proxy ARP.

      + +

      The firewall system itself runs a DHCP server that serves the local + network.

      +

      All administration and publishing is done using ssh/scp.

      - +

      I run an SNMP server on my firewall to serve MRTG running - in the DMZ.

      - + href="http://www.ee.ethz.ch/%7Eoetiker/webtools/mrtg/"> MRTG running + in the DMZ.

      +

      -

      - +

      +

       

      - -

      The ethernet interface in the Server is configured - with IP address 206.124.146.177, netmask - 255.255.255.0. The server's default gateway is - 206.124.146.254 (Router at my ISP. This is the same - default gateway used by the firewall itself). On the firewall, - Shorewall automatically adds a host route to - 206.124.146.177 through eth1 (192.168.2.1) because - of the entry in /etc/shorewall/proxyarp (see -below).

      - -

      A similar setup is used on eth3 (192.168.3.1) which - interfaces to my laptop (206.124.146.180).
      -

      - -

      Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior + +

      The ethernet interface in the Server is configured + with IP address 206.124.146.177, netmask + 255.255.255.0. The server's default gateway is + 206.124.146.254 (Router at my ISP. This is the same + default gateway used by the firewall itself). On the firewall, + Shorewall automatically adds a host route to + 206.124.146.177 through eth1 (192.168.2.1) because + of the entry in /etc/shorewall/proxyarp (see + below).

      + +

      A similar setup is used on eth3 (192.168.3.1) which + interfaces to my laptop (206.124.146.180).
      +

      + +

      Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior access.
      -

      - +

      +

      -
      - +
      +

      Shorewall.conf

      - + 
      	SUBSYSLOCK=/var/lock/subsys/shorewall
      	STATEDIR=/var/state/shorewall

      	LOGRATE=
      	LOGBURST=

      	ADD_IP_ALIASES="Yes"

      	CLAMPMSS=Yes

      	MULTIPORT=Yes
      - +

      Zones File:

      - + 
      	#ZONE 	DISPLAY 	COMMENTS
      	net	Internet	Internet
      	me	Eastep		My Workstation
      	loc	Local		Local networks
      	dmz	DMZ		Demilitarized zone
      	tx	Texas		Peer Network in Dallas Texas
      	#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
      - +

      Interfaces File:

      - -
      -

      This is set up so that I can start the firewall before bringing up my -Ethernet interfaces.

      -
      - + +
      +

      This is set up so that I can start the firewall before bringing up +my Ethernet interfaces.

      +
      + 
      	#ZONE    INTERFACE	BROADCAST 	OPTIONS
      	net	eth0 		206.124.146.255	routefilter,norfc1918,blacklist,filterping
      	loc	eth2 		192.168.1.255	dhcp,filterping,maclist
      	dmz	eth1 		206.124.146.255	filterping
      	net	eth3		206.124.146.255 filterping,blacklist
      	-	texas 		-               filterping
      	loc	ppp+		-		filterping
      	#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
      - +

      Hosts File:

      - + 
      	#ZONE 		HOST(S)			OPTIONS
      	me		eth2:192.168.1.3,eth2:206.124.146.179
      	tx 		texas:192.168.9.0/24
      	#LAST LINE -- ADD YOUR ENTRIES ABOVE -- DO NOT REMOVE
      - +

      Routestopped File:

      - + 
      	#INTERFACE	HOST(S)
      	eth1		206.124.146.177
      	eth2 		-
      	eth3 		206.124.146.180
      - -

      Common File:

      - -
      	. /etc/shorewall/common.def
      	run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
      -

      Policy File:

      +

      Common File:

      + +
      	. /etc/shorewall/common.def
      	run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
      + +

      Policy File:

      + 
      
 	#SOURCE	DEST	POLICY	LOG LEVEL	LIMIT:BURST
 	me	all	ACCEPT
@@ -146,42 +148,43 @@ Ethernet  interfaces. 
      
 	all	me	CONTINUE	#WARNING: You must be running Shorewall 1.3.1 or later for
      					      #	  this policy to work as expected!!!	
      	loc 	loc 	ACCEPT
      	loc 	net	ACCEPT
      	$FW	loc	ACCEPT
      	$FW	tx	ACCEPT
      	loc	tx	ACCEPT
      	loc	fw	REJECT
      	net	net	ACCEPT
      	net	all	DROP	info		10/sec:40
      	all	all	REJECT	info
      	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOTE
      - -

      Masq File:

      - -
      - -

      Although most of our internal systems use static NAT, my wife's system - (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with - laptops. Also, I masquerade wookie to the peer subnet in Texas.

      -
      +

      Masq File:

      + +
      + +

      Although most of our internal systems use static NAT, my wife's system + (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with + laptops. Also, I masquerade wookie to the peer subnet in Texas.

      +
      + 
      	#INTERFACE 	SUBNET		ADDRESS
      	eth0 		192.168.1.0/24	206.124.146.176
              texas           206.124.146.179 192.168.1.254
      	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - +

      NAT File:

      - + 
      	#EXTERNAL	INTERFACE	INTERNAL	ALL	LOCAL
      	206.124.146.178 eth0 		192.168.1.5 	No 	No
      	206.124.146.179 eth0 		192.168.1.3 	No 	No
      	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - +

      Proxy ARP File:

      - + 
           	#ADDRESS	INTERFACE	EXTERNAL	HAVEROUTE
      	206.124.146.177 eth1 		eth0 		No
      	206.124.146.180	eth3		eth0		No
      	#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
      - +

      Tunnels File (Shell variable TEXAS set in /etc/shorewall/params):

      - + 
      	#TYPE           ZONE    GATEWAY	
      	gre             net     $TEXAS
      	#LAST LINE -- DO NOT REMOVE
      - -

      Rules File (The shell variables - are set in /etc/shorewall/params):

      - + +

      Rules File (The shell variables + are set in /etc/shorewall/params):

      + 
           	#ACTION		SOURCE 		DEST 			PROTO	DEST 	SOURCE  ORIGINAL
      	#                       				PORT(S) PORT(S)	PORT(S)	DEST
      	#
      	# Local Network to Internet - Reject attempts by Trojans to call home
      	#
      	REJECT:info 	loc 		net 			tcp	6667
      	#
      	# Local Network to Firewall 
      	#
      	ACCEPT		loc		fw 			tcp 	ssh
      	ACCEPT		loc		fw			tcp	time
      	#
      	# Local Network to DMZ 
      	#
      	ACCEPT 		loc 		dmz 			udp	domain
      	ACCEPT		loc		dmz			tcp	smtp
      	ACCEPT		loc		dmz			tcp	domain
      	ACCEPT		loc		dmz			tcp	ssh
      	ACCEPT		loc		dmz			tcp	auth
      	ACCEPT		loc		dmz			tcp	imap
      	ACCEPT		loc		dmz			tcp	https
      	ACCEPT		loc		dmz			tcp	imaps
      	ACCEPT		loc		dmz			tcp	cvspserver
      	ACCEPT 		loc 		dmz 			tcp 	www
      	ACCEPT		loc		dmz			tcp	ftp
      	ACCEPT		loc		dmz			tcp	pop3
      	ACCEPT		loc		dmz			icmp	echo-request
      	#
      	# Internet to DMZ 
      	#
      	ACCEPT		net		dmz 			tcp	www
      	ACCEPT		net		dmz			tcp	smtp
      	ACCEPT		net		dmz			tcp	ftp
      	ACCEPT		net		dmz			tcp	auth
      	ACCEPT		net		dmz			tcp	https
      	ACCEPT		net		dmz			tcp	imaps
      	ACCEPT		net		dmz			tcp	domain
      	ACCEPT		net		dmz			tcp	cvspserver
      	ACCEPT		net		dmz			udp	domain
      	ACCEPT		net		dmz			icmp	echo-request
      	ACCEPT 		net:$MIRRORS	dmz			tcp	rsync
      	#
      	# Net to Me (ICQ chat and file transfers) 
      	#
      	ACCEPT		net		me			tcp	4000:4100
      	#
      	# Net to Local 
      	#
      	ACCEPT		net		loc			tcp	auth
      	REJECT		net		loc			tcp	www
      	ACCEPT		net		loc:192.168.1.5		tcp	1723
      	ACCEPT		net		loc:192.168.1.5		gre
      	#
      	# DMZ to Internet
      	#
      	ACCEPT		dmz		net			icmp	echo-request
      	ACCEPT		dmz		net			tcp	smtp
      	ACCEPT		dmz		net			tcp	auth
      	ACCEPT		dmz		net			tcp	domain
      	ACCEPT		dmz		net			tcp	www
      	ACCEPT		dmz		net			tcp	https
      	ACCEPT		dmz		net			tcp	whois
      	ACCEPT		dmz		net			tcp	echo
      	ACCEPT		dmz		net			udp	domain
      	ACCEPT		dmz 		net:$NTPSERVERS		udp	ntp
      	ACCEPT 		dmz 		net:$POPSERVERS		tcp	pop3
      	#
      	# The following compensates for a bug, either in some FTP clients or in the
      	# Netfilter connection tracking code that occasionally denies active mode
      	# FTP clients
      	#
      	ACCEPT:info 	dmz 		net			tcp	1024:	20
      	#
      	# DMZ to Firewall -- snmp
      	#
      	ACCEPT 		dmz 		fw 			tcp	snmp
      	ACCEPT		dmz		fw			udp	snmp
      	#
      	# DMZ to Local Network 
      	#
      	ACCEPT 		dmz 		loc			tcp	smtp
      	ACCEPT		dmz		loc			tcp	auth
      	ACCEPT		dmz		loc			icmp	echo-request
      	# Internet to Firewall
      	#
      	REJECT 		net		fw			tcp	www
      	#
      	# Firewall to Internet
      	#
      	ACCEPT 		fw 		net:$NTPSERVERS		udp	ntp
      	ACCEPT		fw		net			udp	domain
      	ACCEPT		fw		net			tcp	domain
      	ACCEPT		fw		net			tcp	www
      	ACCEPT		fw		net			tcp	https
      	ACCEPT		fw		net			tcp	ssh
      	ACCEPT		fw		net			tcp	whois
      	ACCEPT		fw		net 			icmp	echo-request
      	#
      	# Firewall to DMZ
      	#
      	ACCEPT 		fw 		dmz 			tcp 	www
      	ACCEPT 		fw 		dmz 			tcp 	ftp
      	ACCEPT 		fw 		dmz 			tcp 	ssh
      	ACCEPT 		fw 		dmz 			tcp 	smtp
      	ACCEPT 		fw 		dmz 			udp 	domain
      	#
      	# Let Texas Ping
      	#
      	ACCEPT 		tx 		fw 			icmp 	echo-request
      	ACCEPT		tx 		loc 			icmp 	echo-request

      	#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
      - -

      Last updated 1/12/2003 - - Tom Eastep + +

      Last updated 1/12/2003 - + Tom Eastep

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

      diff --git a/STABLE/documentation/ping.html b/STABLE/documentation/ping.html index c79bf4bcd..fdf4b1126 100644 --- a/STABLE/documentation/ping.html +++ b/STABLE/documentation/ping.html @@ -2,89 +2,149 @@ ICMP Echo-request (Ping) + + - + + - - - + + - - - + + + +
      +

      ICMP Echo-request (Ping)

      -
      -
      -Shorewall 'Ping' management has evolved over time in a less than consistant -way. This page describes how it now works.
      -
      -There are several aspects to Shorewall Ping management:
      -
        -
      1. The noping and filterping interface options in /etc/shorewall/interfaces.
        2. -
      2. The FORWARDPING option in /etc/shorewall/shorewall.conf.
        3. -
      3. Explicit rules in /etc/shorewall/rules.
        4. -
      -There are two cases to consider:
      -
        -
      1. Ping requests addressed to the firewall itself; and
        2. -
      2. Ping requests being forwarded to another system. Included here are -all cases of packet forwarding including NAT, DNAT rule, Proxy ARP and simple -routing.
        3. -
      -These cases will be covered separately.
      -

      Ping Requests Addressed to the Firewall Itself

      -For ping requests addressed to the firewall, the sequence is as follows:
      -
        -
      1. If neither noping nor filterping are specified for the -interface that receives the ping request then the request will be responded -to with an ICMP echo-reply.
        2. -
      2. If noping is specified for the interface that receives the ping -request then the request is ignored.
        3. -
      3. If filterping is specified for the interface then the request -is passed to the rules/policy evaluation.
        4. -
      -

      Ping Requests Forwarded by the Firewall

      -These requests are always passed to rules/policy evaluation.
      -

      Rules Evaluation

      -Ping requests are ICMP type 8. So the general rule format is:
      -
      -    Target    Source    Destination    -icmp    8
      -
      -Example 1. Accept pings from the net to the dmz (pings are responded to with -an ICMP echo-reply):
      -
      -    ACCEPT    net    dmz    -icmp    8
      -
      -Example 2. Drop pings from the net to the firewall
      -
      -    DROP    net    fw    -icmp    8
      -

      Policy Evaluation

      -If no applicable rule is found, then the policy for the source to the destination -is applied.
      -
        -
      1. If the relevant policy is ACCEPT then the request is responded to with -an ICMP echo-reply.
        2. -
      2. If FORWARDPING is set to Yes in /etc/shorewall/shorewall.conf -then the request is responded to with an ICMP echo-reply.
        3. -
      3. Otherwise, the relevant REJECT or DROP policy is used and the request -is either rejected or simply ignored.
        4. -
      -

      Updated 12/13/2002 - Tom Eastep

      +
      + Shorewall 'Ping' management has evolved over time with the latest change +coming in Shorewall version 1.3.14. In that version, a new option (OLD_PING_HANDLING) +was added to /etc/shorewall/shorewall.conf. The value of that option determines +the overall handling of ICMP echo requests (pings).
      -

      Copyright - © 2001, 2002 Thomas M. Eastep.

      +

      Shorewall Versions >= 1.3.14 with OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf

      + In 1.3.14, Ping handling was put under control of the rules and policies +just like any other connection request. In order to accept ping requests from +zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need +a rule in /etc/shoreall/rules of the form:
      + +
      ACCEPT    z1    z2    + icmp    8
      +
      + Example:
      +
      + To permit ping from the local zone to the firewall:
      + +
      ACCEPT    loc    fw    +icmp    8
      +
      + If you would like to accept 'ping' by default even when the relevant +policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't +already exist and in that file place the following command:
      + +
      + 
      run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
      +
      + With that rule in place, if you want to ignore 'ping' from z1 to z2 then +you need a rule of the form:
      + +
      DROP    z1    z2    + icmp    8
      +
      + Example:
      +
      + To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
      + +
      DROP    net    fw    +icmp    8
      +
      + +
      + +

      Shorewall Versions < 1.3.14 or with OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
      +

      + There are several aspects to the old Shorewall Ping management:
      + +
        +
      1. The noping and filterping interface options in /etc/shorewall/interfaces.
        2. +
      2. The FORWARDPING option in +/etc/shorewall/shorewall.conf.
        3. +
      3. Explicit rules in /etc/shorewall/rules.
        4. + +
      + There are two cases to consider:
      + +
        +
      1. Ping requests addressed to the firewall itself; and
        2. +
      2. Ping requests being forwarded to another system. Included here are + all cases of packet forwarding including NAT, DNAT rule, Proxy ARP and simple + routing.
        3. + +
      + These cases will be covered separately.
      + +

      Ping Requests Addressed to the Firewall Itself

      + For ping requests addressed to the firewall, the sequence is as follows:
      + +
        +
      1. If neither noping nor filterping are specified for +the interface that receives the ping request then the request will be responded + to with an ICMP echo-reply.
        2. +
      2. If noping is specified for the interface that receives the +ping request then the request is ignored.
        3. +
      3. If filterping is specified for the interface then the request + is passed to the rules/policy evaluation.
        4. + +
      + +

      Ping Requests Forwarded by the Firewall

      + These requests are always passed to rules/policy evaluation.
      + +

      Rules Evaluation

      + Ping requests are ICMP type 8. So the general rule format is:
      +
      +     Target    Source    +Destination    icmp    8
      +
      + Example 1. Accept pings from the net to the dmz (pings are responded to +with an ICMP echo-reply):
      +
      +     ACCEPT    net    dmz    + icmp    8
      +
      + Example 2. Drop pings from the net to the firewall
      +
      +     DROP    net    fw    + icmp    8
      + +

      Policy Evaluation

      + If no applicable rule is found, then the policy for the source to the destination + is applied.
      + +
        +
      1. If the relevant policy is ACCEPT then the request is responded to +with an ICMP echo-reply.
        2. +
      2. If FORWARDPING is set to Yes in /etc/shorewall/shorewall.conf + then the request is responded to with an ICMP echo-reply.
        3. +
      3. Otherwise, the relevant REJECT or DROP policy is used and the request + is either rejected or simply ignored.
        4. + +
      + +

      Updated 1/21/2003 - Tom Eastep +

      + +

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

      +
      +

      diff --git a/STABLE/documentation/ports.htm b/STABLE/documentation/ports.htm index 4e9c2b71a..4912c722f 100644 --- a/STABLE/documentation/ports.htm +++ b/STABLE/documentation/ports.htm @@ -1,194 +1,203 @@ - + Shorewall Port Information - + - + - + - - - + + - - - + + + +
      -

      Ports required for Various +

      +

      Ports required for Various Services/Applications

      -
      - +

      In addition to those applications described in the /etc/shorewall/rules documentation, here - are some other services/applications that you may need to configure your + href="Documentation.htm">the /etc/shorewall/rules documentation, here + are some other services/applications that you may need to configure your firewall to accommodate.

      - +

      NTP (Network Time Protocol)

      - -
      + +

      UDP Port 123

      -
      - +
      +

      rdate

      - -
      -

      TCP Port 37

      -
      +
      +

      TCP Port 37

      +
      +

      UseNet (NNTP)

      - -
      + +

      TCP Port 119

      -
      - +
      +

      DNS

      - -
      -

      UDP Port 53. If you are configuring a DNS client, you will probably -want to open TCP Port 53 as well.
      - If you are configuring a server, only open TCP Port 53 if you will return - long replies to queries or if you need to enable ZONE transfers. In the - latter case, be sure that your server is properly configured.

      -
      - + +
      +

      UDP Port 53. If you are configuring a DNS client, you will probably want +to open TCP Port 53 as well.
      + If you are configuring a server, only open TCP Port 53 if you will +return long replies to queries or if you need to enable ZONE transfers. In +the latter case, be sure that your server is properly configured.

      +
      +

      ICQ   

      - -
      -

      UDP Port 4000. You will also need to open a range of TCP ports which + +

      +

      UDP Port 4000. You will also need to open a range of TCP ports which you can specify to your ICQ client. By default, clients use 4000-4100.

      -
      - +
      +

      PPTP

      - -
      + +

      Protocol 47 (NOT port 47) and TCP Port 1723 (Lots more information here).

      -
      - -

      IPSEC

      - -
      -

      Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port - 500. These should be opened in both directions (Lots more information - here and here).

      -
      - -

      SMTP

      - -
      -

       TCP Port 25.

      -
      - -

      POP3

      - -
      -

      TCP Port 110.

      -
      - -

      TELNET

      - -
      -

      TCP Port 23.

      -
      - -

      SSH

      - -
      -

      TCP Port 22.

      -
      - -

      Auth (identd)

      - -
      -

      TCP Port 113

      -
      - -

      Web Access

      - -
      -

      TCP Ports 80 and 443.

      -
      +
      +

      IPSEC

      + +
      +

      Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port + 500. These should be opened in both directions (Lots more information + here and here).

      +
      + +

      SMTP

      + +
      +

       TCP Port 25.

      +
      + +

      POP3

      + +
      +

      TCP Port 110.

      +
      + +

      TELNET

      + +
      +

      TCP Port 23.

      +
      + +

      SSH

      + +
      +

      TCP Port 22.

      +
      + +

      Auth (identd)

      + +
      +

      TCP Port 113

      +
      + +

      Web Access

      + +
      +

      TCP Ports 80 and 443.

      +
      +

      FTP

      - -
      + +

      Server configuration is covered on in the /etc/shorewall/rules documentation,

      + +

      For a client, you must open outbound TCP port 21 and be sure that your + kernel is compiled to support FTP connection tracking. If you build this + support as a module, Shorewall will automatically load the module from + /var/lib/<kernel version>/kernel/net/ipv4/netfilter. 
      +

      -

      For a client, you must open outbound TCP port 21 and be sure that your - kernel is compiled to support FTP connection tracking. If you build this - support as a module, Shorewall will automatically load the module from - /var/lib/<kernel version>/kernel/net/ipv4/netfilter. 
      -

      - -

      If you run an FTP server on a nonstandard port or you need to access -such a server, then you must specify that port in /etc/shorewall/modules. -For example, if you run an FTP server that listens on port 49 then you would -have:
      -

      - -
      +

      If you run an FTP server on a nonstandard port or you need to access + such a server, then you must specify that port in /etc/shorewall/modules. + For example, if you run an FTP server that listens on port 49 then you would + have:
      +

      + +

      loadmodule ip_conntrack_ftp ports=21,49
      - loadmodule ip_nat_ftp ports=21,49
      -

      -
      + loadmodule ip_nat_ftp ports=21,49
      +

      +
      + +

      Note that you MUST include port 21 in the ports list or you may + have problems accessing regular FTP servers.

      -

      Note that you MUST include port 21 in the ports list or you may -have problems accessing regular FTP servers.

      - -

      If there is a possibility that these modules might be loaded before -Shorewall starts, then you should include the port list in /etc/modules.conf:
      -

      - -
      +

      If there is a possibility that these modules might be loaded before Shorewall +starts, then you should include the port list in /etc/modules.conf:
      +

      + +

      options ip_conntrack_ftp ports=21,49
      - options ip_nat_ftp ports=21,49
      -

      -
      -
      - + options ip_nat_ftp ports=21,49
      +

      +
      +
      +

      SMB/NMB (Samba/Windows Browsing/File Sharing)

      - +
      - -
      + +

      TCP Ports 137, 139 and 445.
      - UDP Ports 137-139.
      -
      - Also, see this page.

      -
      - + UDP Ports 137-139.
      +
      + Also, see this page.

      +
      +

      Traceroute

      - -
      + +

      UDP ports 33434 through 33434+<max number of hops>-1

      -
      +
      + +

      NFS
      +

      +
      +

      I personally use the following rules for opening access from zone z1 +to a server with IP address a.b.c.d in zone z2:
      +

      + 
      ACCEPT	z1	z2:a.b.c.d	udp	111
      ACCEPT	z1	z2:a.b.c.d	udp	2049
      ACCEPT	z1	z2:a.b.c.d	udp	32700:
      +
      -

      NFS

      - -
      -

      There's some good information at  +

      Note that my rules only cover NFS using UDP (the normal case). There +is lots of additional information at  http://nfs.sourceforge.net/nfs-howto/security.html

      -
      - -

      Didn't find what you are looking for -- have you looked in your own -/etc/services file?

      - + + +

      Didn't find what you are looking for -- have you looked in your own /etc/services +file?

      +

      Still looking? Try http://www.networkice.com/advice/Exploits/Ports

      - -

      Last updated 11/10/2002 - Last updated 2/7/2003 - Tom Eastep

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


      diff --git a/STABLE/documentation/seattlefirewall_index.htm b/STABLE/documentation/seattlefirewall_index.htm index 8d739d4a9..5e0a09cab 100644 --- a/STABLE/documentation/seattlefirewall_index.htm +++ b/STABLE/documentation/seattlefirewall_index.htm @@ -5,7 +5,8 @@ - + + Shoreline Firewall (Shorewall) 1.3 @@ -13,36 +14,40 @@ - + + - + + - + - + - + - + - + - +
      + - - + + +

      Shorwall Logo - Shorewall 1.3 -- "iptables made easy"

      + Shorewall + 1.3 - "iptables + made easy" @@ -50,41 +55,43 @@ - + + + -
      +
      -
      - + +
      - +
      - + - + - + - + - + - + - + - +
      + @@ -92,7 +99,8 @@ - + +

      What is it?

      @@ -102,7 +110,9 @@ - + + +

      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 @@ -115,26 +125,30 @@ firewall that can be used on a dedicated firewall system, a multi-functio - + + +

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

      + You should have received a copy of + the GNU General Public License along +with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA + 02139, USA

      @@ -143,7 +157,9 @@ General Public License for more details.
      - + + +

      Copyright 2001, 2002, 2003 Thomas M. Eastep

      @@ -154,26 +170,29 @@ General Public License for more details.
      - + +

      - Jacques Nilo and Eric Wolzak have - a LEAF (router/firewall/gateway on a floppy, CD or compact - flash) distribution called Bering that - features Shorewall-1.3.10 and Kernel-2.4.18. You - can find their work at: Jacques Nilo and Eric Wolzak + have a LEAF (router/firewall/gateway on a floppy, + CD or compact flash) distribution called Bering + that features Shorewall-1.3.10 and Kernel-2.4.18. + You can find their work at: http://leaf.sourceforge.net/devel/jnilo
      -

      +

      - + +

      Congratulations to Jacques and Eric on the recent release of Bering 1.0 Final!!!
      -

      +

      - + +

      This is a mirror of the main Shorewall web site at SourceForge (http://shorewall.sf.net)

      @@ -187,7 +206,8 @@ Bering 1.0 Final!!!
      - + +

      News

      @@ -197,294 +217,127 @@ Bering 1.0 Final!!!
      - + + +

      - -

      1/13/2003 - Shorewall 1.3.13 (New) -
      -

      + + + +

      2/8/2003 - Shoreawll 1.3.14 (New) +

      -

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

      +

      New features include

        -
      1. A new 'DNAT-' action has been added for entries in the /etc/shorewall/rules -file. DNAT- is intended for advanced users who wish to minimize the number -of rules that connection requests must traverse.
        +
      2. An OLD_PING_HANDLING option has been added to shorewall.conf. +When set to Yes, Shorewall ping handling is as it has always been (see +http://www.shorewall.net/ping.html).
        +
        + When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and +policies just like any other connection request. The FORWARDPING=Yes option +in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces +will all generate an error.
        +
        +
        3. +
      3. It is now possible to direct Shorewall to create a "label" such + as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes +and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead +of just the interface name:
        +  
        +    a) In the INTERFACE column of /etc/shorewall/masq
        +    b) In the INTERFACE column of /etc/shorewall/nat
        +  
        4. +
      4. Support for OpenVPN Tunnels.

        - 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,....
        +
        5. +
      5. Support for VLAN devices with names of the form $DEV.$VID (e.g., +eth0.0)

        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. +
      9. When an interface name is entered in the SUBNET column of the +/etc/shorewall/masq file, Shorewall previously masqueraded traffic from +only the first subnet defined on that interface. It did not masquerade +traffic from:
        +  
        +    a) The subnets associated with other addresses on the interface.
        +    b) Subnets accessed through local routers.
        +  
        + Beginning with Shorewall 1.3.14, if you enter an interface name in the + SUBNET column, shorewall will use the firewall's routing table to construct + the masquerading/SNAT rules.
        +  
        + Example 1 -- This is how it works in 1.3.14.
        +   
        + + 
           [root@gateway test]# cat /etc/shorewall/masq
           #INTERFACE              SUBNET                  ADDRESS
           eth0                    eth2                    206.124.146.176
           #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
        + + 
           [root@gateway test]# ip route show dev eth2
           192.168.1.0/24  scope link
           192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
        + + 
           [root@gateway test]# shorewall start
           ...
           Masqueraded Subnets and Hosts:
               To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
               To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
           Processing /etc/shorewall/tos...
        +  
        + When upgrading to Shorewall 1.3.14, if you have multiple local subnets + connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq + entry, your /etc/shorewall/masq file will need changing. In most cases, +you will simply be able to remove redundant entries. In some cases though, +you might want to change from using the interface name to listing specific +subnetworks if the change described above will cause masquerading to occur +on subnetworks that you don't wish 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
        +
      -

      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

      - - -

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

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

        + Webmin version 1.060 now has Shorewall support included as standard. See + http://www.webmin.com. + +

        -
      - -

      12/20/2002 - Shorewall 1.3.12 Beta 3
      -

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

      You may download the Beta from:
      -

      - -
      http://www.shorewall.net/pub/shorewall/Beta
      - ftp://ftp.shorewall.net/pub/shorewall/Beta
      -
      - - -

      12/20/2002 - Shorewall 1.3.12 Beta 2 -

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

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

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

      12/7/2002 - Shorewall Support for Mandrake 9.0 -

      - - -

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

      - - -

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

      - - - -

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

      - - - -

      12/3/2002 - Shorewall 1.3.11a -

      - - - -

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

      - - - -

      11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format -

      - - - -

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

      - - - -

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

      - - - -

      11/24/2002 - Shorewall 1.3.11  -

      - - - -

      In this version:

      - - - +

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

      More News

      @@ -495,39 +348,41 @@ is now compatible with bash clones such as ash and dash. - + +

      Donations

      -       		M M
      -
      + -
      + - + - + - + - + - + - + - +
      + @@ -535,12 +390,13 @@ is now compatible with bash clones such as ash and dash. - + +

      -   -

      + +  

      @@ -549,31 +405,31 @@ is now compatible with bash clones such as ash and dash. - + +

      Shorewall is free but if you try it and find it useful, please consider making a donation - to Starlight Children's Foundation. Thanks!

      -
      - -

      Updated 1/13/2003 - Tom Eastep + +

      Updated 2/7/2003 - Tom Eastep -
      -

      -
      +
      +

      diff --git a/STABLE/documentation/shoreline.htm b/STABLE/documentation/shoreline.htm index 3a7104254..f1b1ba204 100644 --- a/STABLE/documentation/shoreline.htm +++ b/STABLE/documentation/shoreline.htm @@ -1,125 +1,126 @@ - + About the Shorewall Author - + - - + + - + - - - + + - - - + + + +
      - +
      +

      Tom Eastep

      -
      - +

      Tom on the PCT - 1991 -

      - +

      +

      Tarry & Tom -- August 2002
      -
      -

      - +
      +

      + - -

      I am currently a member of the design team for the next-generation - operating system from the NonStop Enterprise Division of HP.

      - -

      I became interested in Internet Security when I established a home office - in 1999 and had DSL service installed in our home. I investigated - ipchains and developed the scripts which are now collectively known as - Seattle Firewall. Expanding - on what I learned from Seattle Firewall, I then designed and wrote - Shorewall.

      - -

      I telework from our home in Shoreline, - Washington where I live with my wife Tarry.

      - -

      Our current home network consists of:

      +
    7. Tandem Computers, Incorporated + (now part of the The New HP) 1980 +- present
      8. +
    8. Married 1969 - no children.
      9. -
        -
      • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB & 20GB - IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. -Serves as a PPTP server for Road Warrior access. Also has Mandrake 9.0 installed.
        • -
      • Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip) - NIC - My personal Linux System which runs Samba configured as a -WINS server. This system also has VMware installed and can run -both Debian Woody and SuSE 8.1 in virtual machines.
        • -
      • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  -- Email (Postfix & Courier-IMAP), HTTP (Apache), FTP (Pure_ftpd), -DNS server (Bind).
        • -
      • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 LNE100TX  - (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.12+  and a -DHCP server.
        • -
      • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - My - wife's personal system.
        • -
      • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard -EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My main -work system.
        • -
      - + +

      I am currently a member of the design team for the next-generation + operating system from the NonStop Enterprise Division of HP.

      + +

      I became interested in Internet Security when I established a home office + in 1999 and had DSL service installed in our home. I investigated + ipchains and developed the scripts which are now collectively known as + Seattle Firewall. Expanding + on what I learned from Seattle Firewall, I then designed and wrote + Shorewall.

      + +

      I telework from our home in Shoreline, + Washington where I live with my wife Tarry.

      + +

      Our current home network consists of:

      + +
        +
      • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB & 20GB + IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. Serves +as a PPTP server for Road Warrior access. Dual boots Mandrake 9.0.
        • +
      • Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip) + NIC - My personal Linux System which runs Samba configured as a +WINS server. This system also has VMware installed and can run both + Debian Woody and SuSE 8.1 in virtual machines.
        • +
      • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  +- Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP (Pure_ftpd), +DNS server (Bind 9).
        • +
      • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 LNE100TX  + (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.14  and a DHCP + server.
        • +
      • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - +My wife's personal system.
        • +
      • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard + EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My main + work system.
        • + +
      +

      For more about our network see my Shorewall Configuration.

      - +

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

      - +

      - - - - Powered by Mandrake - Protected by ShorewallProtected by Shorewall -

      - -

      Last updated 1/7/2003 -

      + +

      Last updated 1/24/2003 - Tom Eastep

      - Copyright © 2001, 2002, 2003 Thomas + Copyright © 2001, 2002, 2003 Thomas M. Eastep.
      +
      diff --git a/STABLE/documentation/shorewall_features.htm b/STABLE/documentation/shorewall_features.htm index 87c11864a..ec305966e 100644 --- a/STABLE/documentation/shorewall_features.htm +++ b/STABLE/documentation/shorewall_features.htm @@ -1,111 +1,118 @@ - + - + - + - + Shorewall Features - + - - - + + - - - + + + +
      +

      Shorewall Features

      -
      - + - -

      Last updated 11/09/2002 - Tom Eastep

      - + +

      Last updated 2/5/2003 - Tom Eastep

      +

      Copyright © 2001,2002 Thomas M. Eastep.
      -

      + size="2">Copyright       © 2001-2003 Thomas M. Eastep.
      +

      +
      +
      diff --git a/STABLE/documentation/shorewall_mirrors.htm b/STABLE/documentation/shorewall_mirrors.htm index 74c790487..9d1df357c 100644 --- a/STABLE/documentation/shorewall_mirrors.htm +++ b/STABLE/documentation/shorewall_mirrors.htm @@ -45,7 +45,7 @@ and is located in California, USA. It is mirrored at:

      (Martinez (Zona Norte - GBA), Argentina)
    9. http://france.shorewall.net (Paris, France)
      10. -
    10. http://www.shorewall.net +
    11. http://www.shorewall.net (Washington State, USA)
      12. diff --git a/STABLE/documentation/shorewall_quickstart_guide.htm b/STABLE/documentation/shorewall_quickstart_guide.htm index 4e34d188e..5d90139ad 100644 --- a/STABLE/documentation/shorewall_quickstart_guide.htm +++ b/STABLE/documentation/shorewall_quickstart_guide.htm @@ -1,288 +1,301 @@ - + - + - + - + Shorewall QuickStart Guide - + - + - - - + + - - - + (HOWTO's)
      + Version 3.1 + + + +
      +
      - +

      Shorewall QuickStart Guides -(HOWTO's)
      - Version 3.1

      -
      - +

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

      - +must all first walk before we can run.
      + The French Translations are courtesy of Patrice Vetsel
      +

      +

      The Guides

      - -

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

      - -

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

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

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

      - -

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

      - - - -

      Documentation Index

      - -

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

      - - + +

      Documentation Index

      + +

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

      + + - +

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

      - -

      Last modified 1/9/2003 - Tom Eastep

      - + +

      Last modified 2/4/2003 - Tom Eastep

      +

      Copyright 2002, 2003 Thomas M. -Eastep
      -

      + Eastep
      +

      +
      +


      diff --git a/STABLE/documentation/sourceforge_index.htm b/STABLE/documentation/sourceforge_index.htm index 846e87f39..f1733f3f1 100644 --- a/STABLE/documentation/sourceforge_index.htm +++ b/STABLE/documentation/sourceforge_index.htm @@ -5,7 +5,8 @@ - + + Shoreline Firewall (Shorewall) 1.3 @@ -13,22 +14,23 @@ - + + - + + - + - + - - + + + - - + +
      + @@ -36,15 +38,18 @@ - + + +

      Shorwall Logo - Shorewall - 1.3 - "iptables made - easy"

      + Shorewall + 1.3 - "iptables + made easy" + @@ -53,32 +58,35 @@ - + + -
      - -
      + + +
      + +
      -
      - - + - + - - - - - - - - - - - - -
      + @@ -87,7 +95,8 @@ - + +

      What is it?

      @@ -98,11 +107,13 @@ - -

      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.

      @@ -112,26 +123,31 @@ firewall that can be used on a dedicated firewall system, a multi-functio - -

      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

      @@ -141,7 +157,9 @@ hope that it will be useful, but WITHOUT ANY - + + +

      Copyright 2001, 2002, 2003 Thomas M. Eastep

      @@ -153,21 +171,24 @@ hope that it will be useful, but WITHOUT ANY - + +

      - Jacques Nilo and Eric Wolzak - have a LEAF (router/firewall/gateway on a floppy, CD - or compact flash) distribution called Bering - that features Shorewall-1.3.10 and Kernel-2.4.18. - You can find their work at: http://leaf.sourceforge.net/devel/jnilo

      - Congratulations to Jacques and Eric on -the recent release of Bering 1.0 Final!!!
      -       + Jacques Nilo and Eric + Wolzak have a LEAF (router/firewall/gateway on +a floppy, CD or compact flash) distribution called + Bering that features Shorewall-1.3.10 + and Kernel-2.4.18. You can find their work at: + http://leaf.sourceforge.net/devel/jnilo

      + Congratulations to Jacques and + Eric on the recent release of Bering 1.0 Final!!!
      +       - + + +

      News

      @@ -181,401 +202,128 @@ the recent release of Bering 1.0 Final!!!
      - -

      1/13/2003 - Shorewall 1.3.13 (New) -
      -

      + + +

      2/8/2003 - Shoreawll 1.3.14 (New) +

      -

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

      +

      New features include

        -
      1. A new 'DNAT-' action has been added for entries in the /etc/shorewall/rules -file. DNAT- is intended for advanced users who wish to minimize the number -of rules that connection requests must traverse.
        +
      2. An OLD_PING_HANDLING option has been added to shorewall.conf. +When set to Yes, Shorewall ping handling is as it has always been (see +http://www.shorewall.net/ping.html).
        +
        + When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and +policies just like any other connection request. The FORWARDPING=Yes option +in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces +will all generate an error.
        +
        +
        3. +
      3. It is now possible to direct Shorewall to create a "label" such + as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes +and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead +of just the interface name:
        +  
        +    a) In the INTERFACE column of /etc/shorewall/masq
        +    b) In the INTERFACE column of /etc/shorewall/nat
        +  
        4. +
      4. Support for OpenVPN Tunnels.

        - 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,....
        +
        5. +
      5. Support for VLAN devices with names of the form $DEV.$VID (e.g., +eth0.0)

        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. +
      9. When an interface name is entered in the SUBNET column of the +/etc/shorewall/masq file, Shorewall previously masqueraded traffic from +only the first subnet defined on that interface. It did not masquerade +traffic from:
        +  
        +    a) The subnets associated with other addresses on the interface.
        +    b) Subnets accessed through local routers.
        +  
        + Beginning with Shorewall 1.3.14, if you enter an interface name in the + SUBNET column, shorewall will use the firewall's routing table to construct + the masquerading/SNAT rules.
        +  
        + Example 1 -- This is how it works in 1.3.14.
        +   
        + + 
           [root@gateway test]# cat /etc/shorewall/masq
           #INTERFACE              SUBNET                  ADDRESS
           eth0                    eth2                    206.124.146.176
           #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
        + + 
           [root@gateway test]# ip route show dev eth2
           192.168.1.0/24  scope link
           192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
        + + 
           [root@gateway test]# shorewall start
           ...
           Masqueraded Subnets and Hosts:
               To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
               To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
           Processing /etc/shorewall/tos...
        +  
        + When upgrading to Shorewall 1.3.14, if you have multiple local subnets + connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq + entry, your /etc/shorewall/masq file will need changing. In most cases, +you will simply be able to remove redundant entries. In some cases though, +you might want to change from using the interface name to listing specific +subnetworks if the change described above will cause masquerading to occur +on subnetworks that you don't wish 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
        +
      -

      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

      - - -

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

      You may download the Beta from:
      -

      - -
      http://www.shorewall.net/pub/shorewall/Beta
      - ftp://ftp.shorewall.net/pub/shorewall/Beta
      -
      - - -

      12/20/2002 - Shorewall 1.3.12 Beta 2 -

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

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

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

      12/7/2002 - Shorewall Support for Mandrake 9.0 -

      - - -

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

      - - -

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

      - - - -

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

      - - - -

      12/3/2002 - Shorewall 1.3.11a -

      - - - -

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

      - - - -

      11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format -

      - - - -

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

      - - - -

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

      - - - -

      11/24/2002 - Shorewall 1.3.11 -

      - - - -

      In this version:

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

      11/14/2002 - Shorewall Documentation in PDF Format -

      - - - -

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

      - - - -

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

      - - - + +

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

      + Webmin version 1.060 now has Shorewall support included as standard. +See http://www.webmin.com +

      - -
        - -
      - - - - -

      More News

      +
        - - - - - -

        - - - - -

        SourceForge Logo -

        - - - - -

        - - - - -

        This site is hosted by the generous folks at SourceForge.net

        - - - - -

        Donations

        - -

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

      - - - + +

      SourceForge Logo +

      + + + + + +

      + + + + + +

      This site is hosted by the generous folks at SourceForge.net

      + + + + + + +

      Donations

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

      More News

      - -

      - -

      @@ -586,30 +334,122 @@ is now compatible with bash clones such as ash and dash. -

      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 1/6/2003 - Tom Eastep - -
      -

      -
      + + +

      Updated 2/7/2003 - Tom Eastep + +
      +

      diff --git a/STABLE/documentation/spam_filters.htm b/STABLE/documentation/spam_filters.htm index b230cdda6..b44664292 100644 --- a/STABLE/documentation/spam_filters.htm +++ b/STABLE/documentation/spam_filters.htm @@ -1,44 +1,62 @@ + - - - - - -SPAM Filters + + + + + + + + + SPAM Filters - - - - - - - + + +
      -

      SPAM Filters

      -
      + + + + + +
      +

      SPAM Filters

      +
      - +


      - -

      -

      Like all of you, I'm concerned about the increasing volume of Unsolicited -Commercial Email (UCE or SPAM). I am therefore sympathetic with those of you who -are installing SPAM filters on your mail servers. A couple of recent incidents -involving mis-configured filters have prompted me to establish this page to spell -out what I will do when these filters bounce list postings.

      + (SpamAssassin Logo) + + + +

      Like all of you, I'm concerned about the increasing volume of Unsolicited +Commercial Email (UCE or SPAM). I am therefore sympathetic with those of +you who are installing SPAM filters on your mail servers. A couple of recent +incidents involving mis-configured filters have prompted me to establish +this page to spell out what I will do when these filters bounce list postings.

      +

      When your SPAM filter bounces/rejects list mail, I will:

      +
        -
      1. immediately turn off delivery to you from all Shorewall lists to -which you subscribe.
        2. -
      2. try to send you an email from a source other than shorewall.net
        3. +
      3. immediately turn off delivery to you from all Shorewall lists to which +you subscribe.
        4. +
      4. try to send you an email from a source other than shorewall.net
        5. +
      -

      When you have corrected the problem, please let me know and I will re-enable + +

      When you have corrected the problem, please let me know and I will re-enable delivery (or you can reenable delivery yourself).

      -

      Last Updated 3/21/2002 - Tom Eastep

      - -

      Copyright -© 2001, 2002 Thomas M. Eastep.

      - + +

      Last Updated 1/29/2003 - Tom Eastep

      + +

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

      +
      - - \ No newline at end of file + diff --git a/STABLE/documentation/standalone.htm b/STABLE/documentation/standalone.htm index 6aca3a303..da3d40560 100644 --- a/STABLE/documentation/standalone.htm +++ b/STABLE/documentation/standalone.htm @@ -1,429 +1,426 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
      +

      Standalone Firewall

      -
      - +

      Version 2.0.1

      - -

      Setting up Shorewall on a standalone Linux system is very + +

      Setting up Shorewall on a standalone Linux system is very easy if you understand the basics and follow the documentation.

      - -

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

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

      - +
        -
      • Linux system
        • -
      • Single external IP address
        • -
      • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
        • - +
      • Linux system
        • +
      • Single external IP address
        • +
      • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
        • +
      - -

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

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

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

      I recommend that you read through the guide first to familiarize yourself - with what's involved then go back through it again making your configuration - changes.  Points at which configuration changes are recommended are flagged + +

      I recommend that you read through the guide first to familiarize yourself + with what's involved then go back through it again making your configuration + changes.  Points at which configuration changes are recommended are flagged with - .

      - + .

      +

      -     If you edit your configuration files on a Windows system, you must - save them as Unix files if your editor supports that option or you must -run them through dos2unix before trying to use them. Similarly, if you copy -a configuration file from your Windows hard drive to a floppy disk, you must -run dos2unix against the copy before using it with Shorewall.

      - +     If you edit your configuration files on a Windows system, you must + save them as Unix files if your editor supports that option or you must + run them through dos2unix before trying to use them. Similarly, if you +copy a configuration file from your Windows hard drive to a floppy disk, +you must run dos2unix against the copy before using it with Shorewall.

      + - +

      Shorewall Concepts

      - +

      -    The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you only need to deal with a few of - these as described in this guide. After you have installed -Shorewall, download the one-interface sample, -un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall - (they will replace files with the same names that were placed in /etc/shorewall - during Shorewall installation).

      - -

      As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions +     The configuration files for Shorewall are contained in the directory + /etc/shorewall -- for simple setups, you only need to deal with a few of + these as described in this guide. After you have installed Shorewall, download the one-interface sample, + un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall + (they will replace files with the same names that were placed in /etc/shorewall + during Shorewall installation).

      + +

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

      - -

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

      Shorewall views the network where it is running as being composed of a + set of zones. In the one-interface sample configuration, only one zone is defined:

      - + - + + + + + - - - - - - - - - + + + + +
      NameDescription
      NameDescription
      netThe Internet
      netThe Internet
      - +

      Shorewall zones are defined in /etc/shorewall/zones.

      - -

      Shorewall also recognizes the firewall system as its own zone - by default, + +

      Shorewall also recognizes the firewall system as its own zone - by default, the firewall itself is known as fw.

      - -

      Rules about what traffic to allow and what traffic to deny are expressed + +

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

      - + - -

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

      - -

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

      - -
      + +

      For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file +matches the connection request then the first policy in /etc/shorewall/policy +that matches the request is applied. If that policy is REJECT or DROP  +the request is first checked against the rules in /etc/shorewall/common (the +samples provide that file for you).

      + +

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

      + +
      - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
      SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
      SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
      fwnetACCEPT  
      netnetDROPinfo 
      allallREJECTinfo 
      fwnetACCEPT  
      netall
      +       		DROPinfo 
      allallREJECTinfo 
      -
      - -
           fw		net	ACCEPT
           net	all	DROP	info
           all	all	REJECT	info
      - +
      +

      The above policy will:

      - +
        -
      1. allow all connection requests from the firewall to the internet
        2. -
      2. drop (ignore) all connection requests from the internet to your +
      3. allow all connection requests from the firewall to the internet
        4. +
      4. drop (ignore) all connection requests from the internet to your firewall
        5. -
      5. reject all other connection requests (Shorewall requires this +
      6. reject all other connection requests (Shorewall requires this catchall policy).
        7. - +
      - -

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

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

      - +

      External Interface

      - -

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

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

      - +

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

      - +
        -
      • -

        If your external interface is ppp0 or ippp0, +

      • +

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

        -
        • -
      • -

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

        • +
      • +

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

        -
        • - + +
      - -
      + +

      IP Addresses

      -
      - -
      -

      RFC 1918 reserves several Private IP address ranges +

      + +
      +

      RFC 1918 reserves several Private IP address ranges for use in private networks:

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

      These addresses are sometimes referred to as non-routable - because the Internet backbone routers will not forward a packet whose - destination address is reserved by RFC 1918. In some cases though, ISPs - are assigning these addresses then using Network Address Translation +

      + +

      These addresses are sometimes referred to as non-routable + because the Internet backbone routers will not forward a packet whose + destination address is reserved by RFC 1918. In some cases though, ISPs + are assigning these addresses then using Network Address Translation to rewrite packet headers when forwarding to/from the internet.

      - +

      -      Before starting Shorewall, you should look at the IP address -of your external interface and if it is one of the above ranges, you -should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

      -
      - -
      -

      Enabling other Connections

      +      Before starting Shorewall, you should look at the IP address +of your external interface and if it is one of the above ranges, you should + remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

      - -
      -

      If you wish to enable connections from the internet to your + +

      +

      Enabling other Connections

      +
      + +
      +

      If you wish to enable connections from the internet to your firewall, the general format is:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfw<protocol><port>  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfw<protocol><port>  
      -
      + +
      + +
      +

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

      - -
      -

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

      -
      - -
      -
      + +
      +
      - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp80  
      ACCEPTnetfwtcp110  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp80  
      ACCEPTnetfwtcp110  
      -
      +
      +
      + +
      +

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

      - -
      -

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

      -
      - -
      -

      Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you want + +

      +

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

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp22  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTnetfwtcp22  
      -
      -
      - -
      -
           ACCEPT	net	fw	tcp	22
      -
      - -
      + +
      + +

      -     At this point, edit /etc/shorewall/rules to add other connections +     At this point, edit /etc/shorewall/rules to add other connections as desired.

      -
      - -
      -

      Starting and Stopping Your Firewall

      - -
      + +
      +

      Starting and Stopping Your Firewall

      +
      + +

      Arrow -     The installation procedure configures - your system to start Shorewall at system boot but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start -Shorewall before configuration is complete. Once you have completed configuration -of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
      -

      - -

      IMPORTANT: Users of the .deb +     The installation procedure configures + your system to start Shorewall at system boot but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file +/etc/shorewall/startup_disabled.
      +

      + +

      IMPORTANT: Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
      -

      -
      - -
      -

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

      +
      + +
      +

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

      -
      - -
      -

      WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have +

      + +
      +

      WARNING: If you are connected to your firewall from + the internet, do not issue a "shorewall stop" command unless you have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall try" command.

      -
      - -

      Last updated 12/9/2002 - + +

      Last updated 1/26/2003 - Tom Eastep

      - -

      Copyright 2002 Thomas - M. Eastep

      -
      + +

      Copyright 2002, 2003 +Thomas M. Eastep

      +
      +



      diff --git a/STABLE/documentation/starting_and_stopping_shorewall.htm b/STABLE/documentation/starting_and_stopping_shorewall.htm index ad749c6b4..f055e0998 100644 --- a/STABLE/documentation/starting_and_stopping_shorewall.htm +++ b/STABLE/documentation/starting_and_stopping_shorewall.htm @@ -1,13 +1,13 @@ - + - + - + - + Starting and Stopping Shorewall @@ -15,37 +15,38 @@ - + - - + + - + - + - - + +
      + -

      Starting/Stopping and Monitoring - the Firewall

      + +

      Starting/Stopping and Monitoring + the Firewall

      -
      - -

      If you have a permanent internet connection such as DSL or Cable, - I recommend that you start the firewall automatically at boot. Once - you have installed "firewall" in your init.d directory, simply type - "chkconfig --add firewall". This will start the firewall in run -levels 2-5 and stop it in run levels 1 and 6. If you want to configure -your firewall differently from this default, you can use the "--level" -option in chkconfig (see "man chkconfig") or using your favorite + +

      If you have a permanent internet connection such as DSL or Cable, + I recommend that you start the firewall automatically at boot. Once + you have installed "firewall" in your init.d directory, simply type + "chkconfig --add firewall". This will start the firewall in run +levels 2-5 and stop it in run levels 1 and 6. If you want to configure +your firewall differently from this default, you can use the "--level" +option in chkconfig (see "man chkconfig") or using your favorite graphical run-level editor.

      @@ -54,198 +55,278 @@ graphical run-level editor.

      +

      Important Notes:
      -

      - +

      +
        -
      1. Shorewall startup is disabled by default. Once you have configured - your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. - Note: Users of the .deb package must edit /etc/default/shorewall and set - 'startup=1'.
        -
        2. -
      2. If you use dialup, you may want to start the firewall in your - /etc/ppp/ip-up.local script. I recommend just placing "shorewall restart" - in that script.
        3. - +
      3. Shorewall startup is disabled by default. Once you have configured + your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. + Note: Users of the .deb package must edit /etc/default/shorewall and set + 'startup=1'.
        +
        4. +
      4. If you use dialup, you may want to start the firewall in +your /etc/ppp/ip-up.local script. I recommend just placing "shorewall + restart" in that script.
        5. +
      - -

      -

      + +

      +

      - -

      You can manually start and stop Shoreline Firewall using the "shorewall" - shell program:

      + +

      You can manually start and stop Shoreline Firewall using the "shorewall" + shell program:

      - +
        -
      • shorewall start - starts the firewall
        • -
      • shorewall stop - stops the firewall
        • -
      • shorewall restart - stops the firewall (if it's running) - and then starts it again
        • -
      • shorewall reset - reset the packet and byte counters - in the firewall
        • -
      • shorewall clear - remove all rules and chains installed - by Shoreline Firewall
        • -
      • shorewall refresh - refresh the rules involving the broadcast - addresses of firewall interfaces and the black and white lists.
        • - +
      • shorewall start - starts the firewall
        • +
      • shorewall stop - stops the firewall
        • +
      • shorewall restart - stops the firewall (if it's + running) and then starts it again
        • +
      • shorewall reset - reset the packet and byte counters + in the firewall
        • +
      • shorewall clear - remove all rules and chains +installed by Shoreline Firewall
        • +
      • shorewall refresh - refresh the rules involving the broadcast + addresses of firewall interfaces and the black and white lists.
        • +
      -If you include the keyword debug as the first argument, then a shell -trace of the command is produced as in:
      + If you include the keyword debug as the first argument, then a +shell trace of the command is produced as in:
      + 
      	shorewall debug start 2> /tmp/trace
      - -

      The above command would trace the 'start' command and place the trace -information in the file /tmp/trace

      -

      The "shorewall" program may also be used to monitor the firewall.

      + +

      The above command would trace the 'start' command and place the trace information +in the file /tmp/trace
      +

      + +

      The Shorewall State Diagram is shown at the + bottom of this page.
      +

      + +

      The "shorewall" program may also be used to monitor the firewall.

      - +
        -
      • shorewall status - produce a verbose report about the firewall - (iptables -L -n -v)
        • -
      • shorewall show chain - produce a verbose report about - chain (iptables -L chain -n -v)
        • -
      • shorewall show nat - produce a verbose report about the nat table - (iptables -t nat -L -n -v)
        • -
      • shorewall show tos - produce a verbose report about the mangle - table (iptables -t mangle -L -n -v)
        • -
      • shorewall show log - display the last 20 packet log entries.
        • -
      • shorewall show connections - displays the IP connections currently - being tracked by the firewall.
        • -
      • shorewall - show - tc - displays information - about the traffic control/shaping configuration.
        • -
      • shorewall monitor [ delay ] - Continuously display the firewall - status, last 20 log entries and nat. When the log entry display - changes, an audible alarm is sounded.
        • -
      • shorewall hits - Produces several reports about the Shorewall -packet log messages in the current /var/log/messages file.
        • -
      • shorewall version - Displays the installed version number.
        • -
      • shorewall check - Performs a cursory validation of - the zones, interfaces, hosts, rules and policy files. The "check" command does not parse and validate -the generated iptables commands so even though the "check" command +
      • shorewall status - produce a verbose report about the firewall + (iptables -L -n -v)
        • +
      • shorewall show chain - produce a verbose report about + chain (iptables -L chain -n -v)
        • +
      • shorewall show nat - produce a verbose report about the nat + table (iptables -t nat -L -n -v)
        • +
      • shorewall show tos - produce a verbose report about the mangle + table (iptables -t mangle -L -n -v)
        • +
      • shorewall show log - display the last 20 packet log entries.
        • +
      • shorewall show connections - displays the IP connections currently + being tracked by the firewall.
        • +
      • shorewall + show + tc - displays information + about the traffic control/shaping configuration.
        • +
      • shorewall monitor [ delay ] - Continuously display the firewall + status, last 20 log entries and nat. When the log entry display + changes, an audible alarm is sounded.
        • +
      • shorewall hits - Produces several reports about the Shorewall + packet log messages in the current /var/log/messages file.
        • +
      • shorewall version - Displays the installed version number.
        • +
      • shorewall check - Performs a cursory validation + of the zones, interfaces, hosts, rules and policy files. The "check" command does not parse and validate + the generated iptables commands so even though the "check" command completes successfully, the configuration may fail to start. See the - recommended way to make configuration changes described below. + recommended way to make configuration changes described below.
        • -
      • shorewall try configuration-directory [ timeout -] - Restart shorewall using the specified configuration and if an error - occurs or if the timeout option is given and the new configuration - has been up for that many seconds then shorewall is restarted using -the standard configuration.
        • -
      • shorewall deny, shorewall reject, shorewall accept and shorewall - save implement dynamic blacklisting.
        • -
      • shorewall logwatch (added in version 1.3.2) - Monitors the - LOGFILE and produces an audible alarm when new Shorewall - messages are logged.
        • +
      • shorewall try configuration-directory [ timeout + ] - Restart shorewall using the specified configuration and if an +error occurs or if the timeout option is given and the new configuration + has been up for that many seconds then shorewall is restarted using + the standard configuration.
        • +
      • shorewall deny, shorewall reject, shorewall accept and shorewall + save implement dynamic blacklisting.
        • +
      • shorewall logwatch (added in version 1.3.2) - Monitors the + LOGFILE and produces an audible alarm when new + Shorewall messages are logged.
        • + +
      + Finally, the "shorewall" program may be used to dynamically alter the + contents of a zone.
      + +
        +
      • shorewall add interface[:host] zone - Adds + the specified interface (and host if included) to the specified zone.
        • +
      • shorewall delete interface[:host] zone - +Deletes the specified interface (and host if included) from the specified +zone.
      - Finally, the "shorewall" program may be used to dynamically alter the contents - of a zone.
      - -
        -
      • shorewall add interface[:host] zone - Adds the - specified interface (and host if included) to the specified zone.
        • -
      • shorewall delete interface[:host] zone - Deletes - the specified interface (and host if included) from the specified zone.
        • - -
      - +
      Examples:
      - -
      shorewall add ipsec0:192.0.2.24 vpn1 --- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
      - shorewall delete ipsec0:192.0.2.24 vpn1 --- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1
      -
      -
      + +
      shorewall add ipsec0:192.0.2.24 vpn1 + -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
      + shorewall delete ipsec0:192.0.2.24 vpn1 + -- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1
      +
      + - -

      The shorewall start, shorewall restart, shorewall check  and - shorewall try commands allow you to specify which Shorewall configuration - to use:

      - - -
      - -

      shorewall [ -c configuration-directory ] {start|restart|check}
      - shorewall try configuration-directory

      -
      + +

      The shorewall start, shorewall restart, shorewall check  and + shorewall try commands allow you to specify which Shorewall configuration + to use:

      -

      If a configuration-directory is specified, each time that Shorewall - is going to use a file in /etc/shorewall it will first look in the configuration-directory - . If the file is present in the configuration-directory, that file - will be used; otherwise, the file in /etc/shorewall will be used.

      - - +
      -

      When changing the configuration of a production firewall, I recommend - the following:

      +

      shorewall [ -c configuration-directory ] {start|restart|check}
      + shorewall try configuration-directory

      +
      + + +

      If a configuration-directory is specified, each time that Shorewall + is going to use a file in /etc/shorewall it will first look in the configuration-directory + . If the file is present in the configuration-directory, that + file will be used; otherwise, the file in /etc/shorewall will be used.

      - + +

      When changing the configuration of a production firewall, I recommend + the following:

      + + + +
        -
      • mkdir /etc/test
        • +
      • mkdir /etc/test
        • -
      • cd /etc/test
        • +
      • cd /etc/test
        • -
      • <copy any files that you need to change from /etc/shorewall - to . and change them here>
        • +
      • <copy any files that you need to change from /etc/shorewall + to . and change them here>
        • -
      • shorewall -c . check
        • +
      • shorewall -c . check
        • -
      • <correct any errors found by check and check again>
        • +
      • <correct any errors found by check and check again>
        • -
      • /sbin/shorewall try .
        • - +
      • /sbin/shorewall try .
        • +
      - -

      If the configuration starts but doesn't work, just "shorewall restart" - to restore the old configuration. If the new configuration fails to start, - the "try" command will automatically start the old one for you.

      + +

      If the configuration starts but doesn't work, just "shorewall restart" + to restore the old configuration. If the new configuration fails to start, + the "try" command will automatically start the old one for you.

      - +

      When the new configuration works then just

      - +
        -
      • cp * /etc/shorewall
        • +
      • cp * /etc/shorewall
        • -
      • cd
        • +
      • cd
        • -
      • rm -rf /etc/test
        • - +
      • rm -rf /etc/test
        • +
      - -

      Updated 1/9/2003 - Tom Eastep -

      + +

      The Shorewall State Diargram is depicted below.
      +

      +
      (State Diagram) +
      +
      + +

       
      +

      + You will note that the commands that result in state transitions use +the word "firewall" rather than "shorewall". That is because the actual +transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall +on Debian); /sbin/shorewall runs 'firewall" according to the following table:
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      shorewall start
      +       		firewall start
      +
      shorewall stop
      +       		firewall stop
      +
      shorewall restart
      +       		firewall restart
      +
      shorewall add
      +       		firewall add
      +
      shorewall delete
      +       		firewall delete
      +
      shorewall refresh
      +       		firewall refresh
      +
      shorewall try
      +       		firewall -c <new configuration> restart
      + If unsuccessful then firewall start (standard configuration)
      + If timeout then firewall restart (standard configuration)
      +
      +
      + +

      Updated 1/29/2003 - Tom Eastep +

      - -

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

      + +

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

      -
      +
      +
      +
      +



      diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index 36cd9125c..8e6c88b57 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -2,120 +2,128 @@ - + - + - + - + Support - + + - + - - - + + - + + + - - + +
      +
      - + +

      Shorewall Support -

      -
      - -

      Due to "Shorewall burnout", I am currently - not involved in either Shorewall development or Shorewall support. Nevertheless, - the mailing list is being ably manned by other Shorewall users. While I don't answer Shorewall  questions + emailed directly to me, I try to spend some time each day answering questions + on the Shorewall Users Mailing List.

      - +

      -Tom Eastep

      - -

      Before Reporting a Problem

      - There are a number of sources for problem - solution information. Please try these before you post. - + +

      Before Reporting a Problem

      +"Well at least you tried to read the documentation, which is a lot more +than some people on this list appear to do."
      +
      +
      - Wietse Venema - On the Postfix mailing list
      +
      +
      + There are a number of sources for +problem solution information. Please try these before you post. +

      - +

      - + - +

      - +
        -
      • The Troubleshooting Information contains - a number of tips to help you solve 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 Errata has links to download updated + components.
        • +
      - +

      - +
        -
      • The Mailing List Archives - search facility can locate posts about similar problems: -
        • - +
      • The Mailing List +Archives search facility can locate posts about similar problems: +
        • +
      - +

      - +

      Mailing List Archive Search

      - -
      - - -

      Match: - + + + + +

      Match: + - Format: - + Format: + - Sort by: - + Sort by: + -
      - Search:

      - - + +

      Problem Reporting Guidelines

      - "Let me see if I can translate your message into a real-world - example. It would be like saying that you have three rooms at home, -and when you walk into one of the rooms, you detect this strange smell. - Can anyone tell you what that strange smell is?
      -
      - Now, all of us could do some wonderful guessing as to the smell -and even what's causing it. You would be absolutely amazed at the range -and variety of smells we could come up with. Even more amazing is that -all of the explanations for the smells would be completely plausible."
      -
      - + "Let me see if I can translate your message into a real-world + example. It would be like saying that you have three rooms at home, + and when you walk into one of the rooms, you detect this strange smell. + Can anyone tell you what that strange smell is?
      +
      + Now, all of us could do some wonderful guessing as to the +smell and even what's causing it. You would be absolutely amazed +at the range and variety of smells we could come up with. Even more +amazing is that all of the explanations for the smells would be completely +plausible."
      +
      +
      - Russell Mosemann on the Postfix mailing list
      -
      -
      - +
      +
      +

      + +
        +
      • 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.
        -
        + +
          +
        • the exact version of Shorewall you are running.
          +
          + shorewall version
          +
          • -
        • When reporting a problem, ALWAYS include this -information:
          • - -
        - -
          - -
            -
          • 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 addr show
            +
            +
            • +
          - +
            -
          • the complete, exact output of
            -
            - ip route show
            -
            -
            • - +
          • the complete, exact output of
            +
            + ip route show
            +
            +
            • +
          - +
            -
          • If your kernel is modularized, the exact output from
            -
            - lsmod
            -
            -
            • -
          • the exact wording of any ping failure responses.
            -
            -
            • - +
          • If your kernel is modularized, the exact output from
            +
            + lsmod
            +
            +
            • +
          • 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.
            +
            +
            • +
          - -
        - -
          -
        • NEVER include the output of "iptables - -L". Instead, please post the exact output of
          -
          - /sbin/shorewall status
          -
          -           Since that command generates a lot of output, we suggest - that you redirect the output to a file and attach the file to your post
          -
          - /sbin/shorewall status > /tmp/status.txt
          -
          -
          • -
        • As a general matter, please do not edit the diagnostic -information in an attempt to conceal your IP address, netmask, -nameserver addresses, domain name, etc. These aren't secrets, and concealing -them often misleads us (and 80% of the time, a hacker could derive them -anyway from information contained in the SMTP headers of your post).
          • - -
        - -
          - -
        - -

        - -
          - -
        - -

        - -
          -
        • Do you see any "Shorewall" - messages ("/sbin/shorewall show log") - when you exercise the function that is giving you problems? If -so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces - file.
          -
          -
          • -
        • Please include any of the Shorewall configuration files (especially - the /etc/shorewall/hosts file if you have modified that file) - that you think are relevant. If you include /etc/shorewall/rules, - please include /etc/shorewall/policy as well (rules are meaningless unless - one also knows the policies).
          • - -
        - -

        - -
        - -

        - -
          -
        • If an error occurs when -you try to "shorewall start", - include a trace (See the Troubleshooting - section for instructions).
          • - -
        - -

        - -
          -
        • -

          The list server limits posts to 120kb so don't post GIFs of - your network layout, etc. to the Mailing List -- your -post will be rejected.

          -
          • - -
        - The author gratefully acknowleges that the above list was heavily plagiarized - from the excellent LEAF document by Ray Olszewski found -at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
        -

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

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

        -
        - - - - -

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

        - +
          +
        • NEVER include the output of "iptables -L". Instead, if you are having connection + problems of any kind, post the exact output of
          +
          + /sbin/shorewall status
          +
          +           Since that command generates a lot of output, we +suggest that you redirect the output to a file and attach the file to +your post
          +
          + /sbin/shorewall status > /tmp/status.txt
          +
          +
          • +
        • 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).
          • -

          Last Updated 1/9/2002 - Tom Eastep

          - +
        + +
          + +
        + +

        + +
          + +
        + +

        + +
          +
        • Do you see any "Shorewall" + messages ("/sbin/shorewall show log") + when you exercise the function that is giving you problems? If + so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces + file.
          +
          +
          • +
        • Please include any of the Shorewall configuration files + (especially the /etc/shorewall/hosts file if you have modified + that file) that you think are relevant. If you include /etc/shorewall/rules, + please include /etc/shorewall/policy as well (rules are meaningless unless + one also knows the policies).
          • + +
        + +

        + +
          + +
        + +

        + +
          +
        • If an error occurs +when you try to "shorewall start", + include a trace (See the Troubleshooting + section for instructions).
          • + +
        + +

        + +
          +
        • + +

          The list server limits posts to 120kb so don't post GIFs of + your network layout, etc. to the Mailing List -- your + post will be rejected.

          +
          • + +
        + The author gratefully acknowleges that the above list was heavily + plagiarized from the excellent LEAF document by Ray Olszewski + found at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
        + +

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

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

        +
        + + + + +

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

        + + +

        Last Updated 2/4/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 2809537a6..2d1310098 100644 --- a/STABLE/documentation/three-interface.htm +++ b/STABLE/documentation/three-interface.htm @@ -1,1135 +1,1218 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
        - +
        +

        Three-Interface Firewall

        -
        - +

        Version 2.0.1

        - -

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

        - -

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

        - + +

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

        + +

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

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

        Here is a schematic of a typical installation.

        - +

        -

        - -

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

        + +

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

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

        I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are + +

        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 +     The configuration files for Shorewall are contained in the directory + /etc/shorewall -- for simple setups, you will only need to deal with a few of these as described in this guide. After you have installed Shorewall, download the three-interface - sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy -the files to /etc/shorewall (the files will replace files with the same -names that were placed in /etc/shorewall when Shorewall was installed).

        - -

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

        - -

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

        - + href="/pub/shorewall/LATEST.samples/three-interfaces.tgz">three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy + the files to /etc/shorewall (the files will replace files with the same + names that were placed in /etc/shorewall when Shorewall was installed)        .

        + +

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

        + +

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

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

        Zone names are defined in /etc/shorewall/zones.

        - -

        Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

        - -

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

        - + +

        Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

        + +

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

        + - -

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

        - -

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

        - -
        + +

        For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

        + +

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

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

        In the three-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers - on the internet, uncomment that line.

        - +
        + +
        +

        In the three-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers + on the internet, uncomment that line.

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

        The above policy will:

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

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

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

        +

        Network Interfaces

        - +

        -

        - -

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

        - +

        + +

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

        +

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

        - -

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

        - -

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

        - + +

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

        + +

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

        +

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

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

        +

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

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

        +
          -
        • -

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

          -
          • -
        • -

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

          -
          • - +
        • + +

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

          +
          • +
        • + +

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

          +
          • +
        - +

        IP Addresses

        - -

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

        - -
        + +

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

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

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

        -
        - -
        -

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

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

        +
        + +
        +

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

        +
        + +

        Example sub-network:

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

        It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

        -
        - -
        -

        One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

        -
        - -
        + +
        + +
        +

        It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

        +
        + +
        +

        One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

        +
        + +

        -     Your local computers (Local Computers 1 & 2) should -be configured with their default gateway set to the IP address - of the firewall's internal interface and your DMZ computers ( DMZ -Computers 1 & 2) should be configured with their default gateway +     Your local computers (Local Computers 1 & 2) should + be configured with their default gateway set to the IP address + of the firewall's internal interface and your DMZ computers ( DMZ +Computers 1 & 2) should be configured with their default gateway set to the IP address of the firewall's DMZ interface.  

        -
        - -

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

        - -

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

        - +
        + +

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

        + +

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

        +

        -

        - -

        The default gateway for the DMZ computers would be 10.10.11.254 - and the default gateway for the Local computers would be 10.10.10.254.

        - -

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

        - +

        + +

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

        +

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

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

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

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

        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:

        - -
        + +

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

        + +

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

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

        If you don't specify the <server port>, it is assumed to -be the same as <port>.

        - -

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

        - -
        +
        + +

        If you don't specify the <server port>, it is assumed to be +the same as <port>.

        + +

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

        + +
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
        ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
        ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
        -
        - +
        +

        A couple of important points to keep in mind:

        - +
          -
        • When you are connecting to your server from your local systems, - you must use the server's internal IP address (10.10.11.2).
          • -
        • Many ISPs block incoming connection requests to port 80. -If you have problems connecting to your web server, try the following - rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your - external IP).
          • - +
        • When you are connecting to your server from your local + systems, you must use the server's internal IP address (10.10.11.2).
          • +
        • Many ISPs block incoming connection requests to port +80. If you have problems connecting to your web server, try the +following rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your + external IP).
          • +
        - -
        + +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp5000  
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp5000  
        -
        - -

        If you want to be able to access your server from the local network using - your external address, then if you have a static external IP you can - replace the loc->dmz rule above with:

        - -
        +
        + +

        If you want to be able to access your server from the local network using + your external address, then if you have a static external IP you can + replace the loc->dmz rule above with:

        + +
        - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp80-<external IP>
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATnetdmz:10.10.11.2:80tcp80-<external IP>
        -
        - -

        If you have a dynamic ip then you must ensure that your external interface - is up before starting Shorewall and you must take steps as follows +

        + +

        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
        DNATloc
        -         		dmz:10.10.11.2:80tcp80-$ETH0_IP
        ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
        DNATloc
        +         		dmz:10.10.11.2:80tcp80-$ETH0_IP
        -
        - -

        If you want to access your server from the DMZ using your external IP - address, see FAQ 2a.

        - +
        + +

        If you want to access your server from the DMZ using your external IP +address, see FAQ 2a.

        +

        -     At this point, add the DNAT and ACCEPT rules for your servers. -

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

        -
        - -
        -
        +

        +
        + +
        +

        Run name server on DMZ computer 1

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

      Other Connections

      -
      - -
      +
      + +

      The three-interface sample includes the following rules:

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

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

      -
      - -
      + +
      + +
      +

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

      +
      + +

      The sample also includes:

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

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

      -
      - -
      -

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

      -
      - -
      -
      +
      +
      + +
      +

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

      +
      + +
      +

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

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

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

      -
      - -
      -
      +
      +
      + +
      +

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

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

      Those two rules would of course be in addition to the rules - listed above under "If you run the name server on your firewall".

      -
      - -
      -

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

      -
      - -
      -

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

      -
      - -
      -
      +
      +
      + +
      +

      Those two rules would of course be in addition to the rules + listed above under "If you run the name server on your firewall".

      +
      + +
      +

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

      +
      + +
      +

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

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

      +

      (LEAF Logo) +     Bering users will want to add the following two rules to be compatible +with Jacques's Shorewall configuration.
      +

      +
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTloc
      +       		fwudp
      +       		53
      +       		#Allow DNS Cache towork
      +
      ACCEPTlocfwtcp80#Allow weblet to work
      +
      +
      +

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

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

      +
      + +

      Starting and Stopping Your Firewall

      -
      - -
      +
      + +

      Arrow -     The installation procedure configures - your system to start Shorewall at system boot  but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file -/etc/shorewall/startup_disabled.
      -

      - +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file + /etc/shorewall/startup_disabled.
      +

      +

      IMPORTANT: Users of the .deb package must edit /etc/default/shorewall - and set 'startup=1'.
      -

      -
      - -
      -

      The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, -routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

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

      +
      + +
      +

      The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

      +
      + +

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

      -
      - -
      -

      WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you -have added an entry for the IP address that you are connected from -to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the eth1 (your local network) and eth2 (DMZ) + when Shorewall is stopped. If these two interfaces don't connect +to your local network and DMZ or if you want to enable a different +set of hosts, modify /etc/shorewall/routestopped accordingly.

      +
      + + - -

      Last updated 12/20/2002 - + +

      Last updated 1/30/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 6262e83d1..ef83fa92d 100644 --- a/STABLE/documentation/two-interface.htm +++ b/STABLE/documentation/two-interface.htm @@ -1,951 +1,1032 @@ - + - + - + - + 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 + +

      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:

      - + +

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

      Here is a schematic of a typical installation.

      - +

      -

      - -

      If you are running Shorewall under Mandrake 9.0 or later, you can easily - configure the above setup using the Mandrake "Internet Connection Sharing" - applet. From the Mandrake Control Center, select "Network & Internet" - then "Connection Sharing". You should not need to refer to this guide.
      -

      - -

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

      + +

      If you are running Shorewall under Mandrake 9.0 or later, you can easily + configure the above setup using the Mandrake "Internet Connection Sharing" + applet. From the Mandrake Control Center, select "Network & Internet" + then "Connection Sharing". You should not need to refer to this guide.
      +

      + +

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

      - + 
           [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 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 /etc/shorewall - (these files will replace files with the same name).

      - -

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

      - -

      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:

      - + href="/pub/shorewall/LATEST.samples/two-interfaces.tgz">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 instructions + and default entries.

      + +

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

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

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

      - -

      Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

      - -

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

      - + +

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

      + +

      Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

      + +

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

      + - -

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

      - -

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

      - -
      + +

      For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

      + +

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

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

      In the two-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers - on the internet, uncomment that line.

      - +
      + +
      +

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

      The above policy will:

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

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

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

      +

      Network Interfaces

      - +

      -

      - -

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

      + +

      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  -then you will want to set CLAMPMSS=yes in ppp0 or ippp0  + then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

      - -

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

      - + +

      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 that -Shorewall doesn't work at all.

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

      +

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

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

      +
        -
      • -

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

        -
        • -
      • -

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

        -
        • - +
      • + +

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

        +
        • +
      • + +

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

        +
        • +
      - +

      IP Addresses

      - -

      Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you -a single Public IP address. This address may be assigned via -the Dynamic Host Configuration Protocol (DHCP) or as part of -establishing your connection when you dial in (standard modem) or establish -your PPP connection. In rare cases, your ISP may assign you a static -IP address; that means that you configure your firewall's external interface -to use that address permanently. However your external address is -assigned, it will be shared by all of your systems when you access the + +

      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, a subnet -is described using Classless -InterDomain Routing (CIDR) notation with consists of the subnet -address followed by "/24". The "24" refers to the number of consecutive -leading "1" bits from the left of the subnet mask.

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

      +
      + +
      +

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

      +
      + +

      Example sub-network:

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

      It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

      -
      - -
      -

      One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

      -
      - -
      + +
      + +
      +

      It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

      +
      + +
      +

      One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

      +
      + +

      -     Your local computers (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 - your network as shown here:

      - +     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 + your network as shown here:

      +

      -

      - -

      The default gateway for computer's 1 & 2 would be 10.10.10.254.

      - +

      + +

      The default gateway for computer's 1 & 2 would be 10.10.10.254.
      +

      + +

      +     WARNING: Your ISP might assign +your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24 +subnet then you will need to select a DIFFERENT RFC 1918 subnet for your local +network.
      +

      +

      IP Masquerading (SNAT)

      - -

      The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. When one -of your local systems (let's assume computer 1) sends a connection request - to an internet host, the firewall must perform Network Address Translation - (NAT). The firewall rewrites the source address in the packet to - be the address of the firewall's external interface; in other words, -the firewall makes it look as if the firewall itself is initiating the -connection.  This is necessary so that the destination host will be able -to route return packets back to the firewall (remember that packets whose -destination address is reserved by RFC 1918 can't be routed across the -internet so the remote host can't address its response to computer 1). -When the firewall receives a return packet, it rewrites the destination -address back to 10.10.10.1 and forwards the packet on to computer 1.

      - -

      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:

      - + +

      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:

      +
        -
      • -

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

        -
        • -
      • -

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

        -
        • - +
      • + +

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

        +
        • +
      • + +

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

        +
        • +
      - -

      In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. 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 more efficient.
      -
      - +
      + -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, change - them appropriately:
      -

      - +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, change + them appropriately:
      +

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

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

      - -

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

      - -

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

      - -
      + +

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

      + +

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

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

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

      - -
      +
      + +

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

      + +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:10.10.10.2tcp80  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:10.10.10.2tcp80  
      -
      - +
      +

      A couple of important points to keep in mind:

      - + - -
      + +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:10.10.10.2:80tcp5000  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetloc:10.10.10.2:80tcp5000  
      -
      - +
      +

      -     At this point, modify /etc/shorewall/rules to add any DNAT -rules that you require.

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

      Other Connections

      -
      - -
      +
      + +

      The two-interface sample includes the following rules:

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

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

      -
      - -
      + +
      + +
      +

      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 - and connect to that server from your local systems.

      -
      - -
      -

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

      -
      - -
      -
      +
      +
      + +
      +

      That rule allows you to run an SSH server on your firewall + and connect to that server from your local systems.

      +
      + +
      +

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

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

      -
      - -
      -

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

      -
      - -
      -

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

      -
      - -
      -
      +
      +
      + +
      +

      Those two rules would of course be in addition to the rules + listed above under "You can configure a Caching Name Server on your + firewall"

      +
      + +
      +

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

      +
      + +
      +

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

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

      -     Now edit your /etc/shorewall/rules file to add or delete -other connections as required.

      -
      - -
      + +
      + +
      +

      (LEAF Logo) +    Bering users will want to add the following two rules to be compatible +with Jacques's Shorewall configuration.

      +
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTloc
      +       		fwudp
      +       		53
      +       		#Allow DNS Cache towork
      +
      ACCEPTlocfwtcp80#Allow weblet to work
      +
      +
      +
      +


      + +     Now edit your /etc/shorewall/rules file to add or delete + other connections as required.

      +
      + +

      Starting and Stopping Your Firewall

      -
      - -
      +
      + +

      Arrow -     The installation procedure configures - your system to start Shorewall at system boot  but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file -/etc/shorewall/startup_disabled.
      -

      - +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file + /etc/shorewall/startup_disabled.
      +

      +

      IMPORTANT: Users of the .deb package must edit /etc/default/shorewall - and set 'startup=1'.
      -

      -
      - -
      -

      The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, -routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

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

      +
      + +
      +

      The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

      +
      + +

      -     The two-interface sample assumes that you want to enable - routing to/from eth1 (the local network) when Shorewall is stopped. -If your local network isn't connected to eth1 or if you wish to -enable access to/from other hosts, change /etc/shorewall/routestopped -accordingly.

      -
      - -
      -

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

      +
      + + - -

      Last updated 12/20/2002 - + +

      Last updated 1/21/2003 - Tom Eastep

      - -

      Copyright 2002 Thomas - M. Eastep

      + +

      Copyright 2002, 2003 + Thomas M. Eastep

      +
      +

      +



      diff --git a/STABLE/documentation/upgrade_issues.htm b/STABLE/documentation/upgrade_issues.htm index 9e63663a9..88f1cbcd7 100644 --- a/STABLE/documentation/upgrade_issues.htm +++ b/STABLE/documentation/upgrade_issues.htm @@ -1,176 +1,234 @@ - + Upgrade Issues - + - - + + - + - - - + + - - - + + + +
      +
      +

      Upgrade Issues

      -
      - +

      For upgrade instructions see the Install/Upgrade page.

      - + +

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

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

      - + 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 +
      2. Be sure you have a backup -- you + will need to transcribe any Shorewall configuration changes that you have made to the new configuration.
        3. -
      3. 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.
        4. -
      4. 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 !
        5. - +
      5. Replace the shorwall.lrp package + provided on the Bering floppy with the +later one. If you did not obtain the later +version from Jacques's site, see additional +instructions below.
        6. +
      6. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall + entry if present. Then do not forget to + backup root.lrp !
        7. +
      - +

      The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions - for setting up a two-interface firewall plus you also need to add -the following two Bering-specific rules to /etc/shorewall/rules:

      - -
      + 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 + your firewall setup slightly under Shorewall versions 1.3.6 and 1.3.7

      - +
        -
      1. +
      2. +

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

        -
        3. -
      3. + the following rule
        +
        + run_iptables -A newnotsyn -j RETURN +# So that the connection tracking table can be rebuilt
        +                                     # from non-SYN packets + after takeover.
        +  

        +
        4. +

      4. Create /etc/shorewall/common (if you don't already have that file) and include the following:
        -
        - run_iptables -A common -p tcp --tcp-flags - ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
        -                                                                     - #tracking table.
        - . /etc/shorewall/common.def

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

        + +
      - +

      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
      - + +
      +
      	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 11/09/2002 - - Tom Eastep

      - + If you have applications that access these files, those applications + should be modified accordingly.

      + +

      Last updated 1/25/2003 - + Tom Eastep

      +

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

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

      +
      +
      diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index 4d827f543..8f1c374d9 100755 --- a/STABLE/fallback.sh +++ b/STABLE/fallback.sh @@ -5,7 +5,7 @@ # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # Shorewall documentation is available at http://seattlefirewall.dyndns.org # @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.3.13 +VERSION=1.3.14 usage() # $1 = exit status { diff --git a/STABLE/firewall b/STABLE/firewall index e18cbd055..80a4adac3 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -4,7 +4,7 @@ # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # On most distributions, this file should be called: # /etc/rc.d/init.d/shorewall or /etc/init.d/shorewall @@ -374,7 +374,14 @@ chain_base() #$1 = interface { local c=${1%%+*} - echo ${c:=common} + case $c in + *.*) + echo ${c%.*}_${c#*.} + ;; + *) + echo ${c:=common} + ;; + esac } # @@ -599,13 +606,17 @@ validate_interfaces_file() { for option in $options; do case $option in - dhcp|noping|filterping|routestopped|norfc1918|multi|tcpflags) - ;; - routefilter|dropunclean|logunclean|blacklist|proxyarp|maclist|-) - ;; - *) - error_message "Warning: Invalid option ($option) in record \"$r\"" - ;; + dhcp|routestopped|norfc1918|multi|tcpflags) + ;; + routefilter|dropunclean|logunclean|blacklist|proxyarp|maclist|-) + ;; + noping|filterping) + [ -n "$OLD_PING_HANDLING" ] || \ + startup_error "Option $option only allowed with old ping handling" + ;; + *) + error_message "Warning: Invalid option ($option) in record \"$r\"" + ;; esac done @@ -1102,8 +1113,7 @@ validate_policy() # find_broadcasts() { for interface in $all_interfaces; do - interface=`chain_base $interface` - eval bcast=\$${interface}_broadcast + eval bcast=\$`chain_base $interface`_broadcast if [ "x$bcast" = "xdetect" ]; then addr="`ip addr show $interface 2> /dev/null`" if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then @@ -1122,7 +1132,7 @@ find_broadcasts() { # find_interface_broadcasts() # $1 = Interface name { - eval bcast=\$${1}_broadcast + eval bcast=\$`chain_base ${1}`_broadcast if [ "x$bcast" = "xdetect" ]; then addr="`ip addr show $interface 2> /dev/null`" @@ -1414,6 +1424,23 @@ setup_tunnels() # $1 = name of tunnels file echo " PPTP server defined." } + setup_one_openvpn() # $1 = gateway, $2 = kind[:port] + { + case $2 in + *:*) + p=${2#*:} + ;; + *) + p=5000 + ;; + esac + + addrule $inchain -p udp -s $1 --sport $p --dport $p -j ACCEPT + addrule $outchain -p udp -d $1 --sport $p --dport $p -j ACCEPT + + echo " OPENVPN tunnel to $1:$p defined." + } + strip_file tunnels $1 while read kind z gateway z1; do @@ -1441,6 +1468,9 @@ setup_tunnels() # $1 = name of tunnels file pptpserver|PPTPSERVER) setup_pptp_server ;; + openvpn|OPENVPN|openvpn:*|OPENVPN:*) + setup_one_openvpn $gateway $kind + ;; *) error_message "Tunnels of type $kind are not supported:" \ "Tunnel \"$tunnel\" Ignored" @@ -1704,8 +1734,11 @@ setup_nat() { while read external interface internal allints localnat; do expandv external interface internal allints localnat + + iface=${interface%:*} + if [ -n "$ADD_IP_ALIASES" ]; then - qt ip addr del $external dev $interface + qt ip addr del $external dev $iface fi if [ -z "$allints" -o "$allints" = "Yes" -o "$allints" = "yes" ] @@ -1718,9 +1751,9 @@ setup_nat() { -j DNAT --to-destination $internal fi else - addnatrule `input_chain $interface` \ + addnatrule `input_chain $iface` \ -d $external -j DNAT --to-destination $internal - addnatrule `output_chain $interface` \ + addnatrule `output_chain $iface` \ -s $internal -j SNAT --to-source $external fi @@ -1753,7 +1786,7 @@ delete_nat() { # # Process a TC Rule - $marking_chain is assumed to contain the name of the -# marking chain +# default marking chain # process_tc_rule() { @@ -1774,13 +1807,34 @@ process_tc_rule() ;; *) if ! list_search $source $all_interfaces; then - fatal_error "Error: Unknown interface $source" + fatal_error "Error: Unknown interface $source in rule \"$rule\"" fi r="-i $source " ;; esac fi + + if [ "$mark" != "${mark%:*}" ]; then + + [ "$chain" = tcout ] && \ + fatal_error "Chain designator not allowed when source is \$FW; rule \"$rule\"" + + case "${mark#*:}" in + p|P) + chain=tcpre + ;; + f|F) + chain=tcfor + ;; + *) + fatal_error "Invalid chain designator: (${mark#*:}) in rule \"$rule\"" + ;; + esac + + mark="${mark%:*}" + fi + [ "x$dest" = "x-" ] || r="${r}-d $dest " [ "$proto" = "all" ] || r="${r}-p $proto " [ "x$port" = "x-" ] || r="${r}--dport $port " @@ -1811,7 +1865,8 @@ setup_tc1() { # Create the TC mangle chains # - run_iptables -t mangle -N $marking_chain + run_iptables -t mangle -N tcpre + run_iptables -t mangle -N tcfor run_iptables -t mangle -N tcout # # Process the TC Rules File @@ -1827,11 +1882,9 @@ setup_tc1() { # Link to the TC mangle chains from the main chains # - if [ $marking_chain = tcfor ]; then - run_iptables -t mangle -A FORWARD -j tcfor - else - run_iptables -t mangle -A PREROUTING -j tcpre - fi + run_iptables -t mangle -A FORWARD -j tcfor + run_iptables -t mangle -A PREROUTING -j tcpre + run_iptables -t mangle -A OUTPUT -j tcout run_user_exit tcstart @@ -2871,6 +2924,21 @@ rules_chain() # $1 = source zone, $2 = destination zone fatal_error "Error: No appropriate chain for zone $1 to zone $2" } +# +# echo the list of subnets routed out of a given interface +# +get_routed_subnets() # $1 = interface name +{ + local address + local rest + + ip route show dev $1 2> /dev/null | + while read address rest; do + [ "$address" = "${address%/*}" ] && address="${address}/32" + echo $address + done +} + # # Set up Source NAT (including masquerading) # @@ -2879,12 +2947,32 @@ setup_masq() setup_one() { local using - if [ "$interface" = "${interface%:*}" ]; then - destnet="0.0.0.0/0" - else - destnet="${interface#*:}" - interface="${interface%:*}" - fi + case $fullinterface in + *:*:*) + # Both alias name and subnet + destnet="${fullinterface##*:}" + fullinterface="${fullinterface%:*}" + ;; + *:*) + # Alias name OR subnet + case ${fullinterface#*:} in + *.*) + # It's a subnet + destnet="${fullinterface#*:}" + fullinterface="${fullinterface%:*}" + ;; + *) + #it's an alias name + destnet="0.0.0.0/0" + ;; + esac + ;; + *) + destnet="0.0.0.0/0" + ;; + esac + + interface=${fullinterface%:*} if ! list_search $interface $all_interfaces; then fatal_error "Error: Unknown interface $interface" @@ -2900,10 +2988,10 @@ setup_masq() chain=`masq_chain $interface` iface= + source="$subnet" + case $subnet in *.*.*) - source="$subnet" - subnet="-s $subnet" ;; -) # @@ -2916,22 +3004,15 @@ setup_masq() iface="-o $interface" ;; *) - ipaddr="`ip addr show $subnet 2> /dev/null | grep 'inet '`" - source="$subnet" - if [ -z "$ipaddr" ]; then - fatal_error \ - "Interface $subnet must be up before Shorewall starts" - fi - - subnet="`echo $ipaddr | sed s/" "// | cut -d' ' -f2`" - [ -z "`echo "$subnet" | grep '/'`" ] && subnet="${subnet}/32" - subnet="-s $subnet" + subnets=`get_routed_subnets $subnet` + [ -z "$subnets" ] && startup_error "Unable to determine the routes through interface $subnet" + subnet="$subnets" ;; esac if [ -n "$address" -a -n "$ADD_SNAT_ALIASES" ]; then list_search $address $aliases_to_add || \ - aliases_to_add="$aliases_to_add $address $interface" + aliases_to_add="$aliases_to_add $address $fullinterface" fi destination=$destnet @@ -2939,7 +3020,15 @@ setup_masq() if [ -n "$nomasq" ]; then newchain=masq${masq_seq} createnatchain $newchain - addnatrule $chain -d $destnet $iface $subnet -j $newchain + + if [ -n "$subnet" ]; then + for s in $subnet; do + addnatrule $chain -d $destnet $iface -s $s -j $newchain + done + else + addnatrule $chain -d $destnet $iface -j $newchain + fi + masq_seq=$(($masq_seq + 1)) chain=$newchain subnet= @@ -2949,29 +3038,38 @@ setup_masq() for addr in `separate_list $nomasq`; do addnatrule $chain -s $addr -j RETURN done + + source="$source except $nomasq" else destnet="-d $destnet" fi - if [ -n "$address" ]; then - addnatrule $chain $subnet $destnet $iface \ - -j SNAT --to-source $address - using=" using $address" + if [ -n "$subnet" ]; then + for s in $subnet; do + if [ -n "$address" ]; then + addnatrule $chain -s $s $destnet $iface -j SNAT --to-source $address + echo " To $destination from $s through ${interface} using $address" + else + addnatrule $chain -s $s $destnet $iface -j MASQUERADE + echo " To $destination from $s through ${interface}" + fi + done + elif [ -n "$address" ]; then + addnatrule $chain $destnet $iface -j SNAT --to-source $address + echo " To $destination from $source through ${interface} using $address" else - addnatrule $chain $subnet $destnet $iface -j MASQUERADE - using= + addnatrule $chain $destnet $iface -j MASQUERADE + echo " To $destination from $source through ${interface}" fi - [ -n "$nomasq" ] && source="$source except $nomasq" - echo " To $destination from $source through ${interface}${using}" } strip_file masq $1 [ -n "$NAT_ENABLED" ] && echo "Masqueraded Subnets and Hosts:" - while read interface subnet address; do - expandv interface subnet address + while read fullinterface subnet address; do + expandv fullinterface subnet address [ -n "$NAT_ENABLED" ] && setup_one || \ error_message "Warning: NAT disabled; masq rule ignored" done < $TMP_DIR/masq @@ -3195,9 +3293,10 @@ add_ip_aliases() val=${val%% scope*} fi - run_ip addr add ${external}${val} dev $interface + run_ip addr add ${external}${val} dev $interface $label echo "$external $interface" >> ${STATEDIR}/nat - echo " IP Address $external added to interface $interface" + [ -n "$label" ] && label="with $label" + echo " IP Address $external added to interface $interface $label" } set -- $aliases_to_add @@ -3205,6 +3304,14 @@ add_ip_aliases() while [ $# -gt 0 ]; do external=$1 interface=$2 + label= + + if [ "$interface" != "${interface%:*}" ]; then + label="${interface#*:}" + interface="${interface%:*}" + label="label $interface:$label" + fi + primary=`find_interface_address $interface` shift;shift [ "x${primary}" = "x${external}" ] || do_one @@ -3350,11 +3457,14 @@ initialize_netfilter () { # Build the common chain -- called during [re]start and refresh # build_common_chain() { - # - # PING - # - [ -n "$FORWARDPING" ] && \ - run_iptables -A icmpdef -p icmp --icmp-type echo-request -j ACCEPT + + if [ -n "$OLD_PING_HANDLING" ]; then + # + # PING + # + [ -n "$FORWARDPING" ] && \ + run_iptables -A icmpdef -p icmp --icmp-type echo-request -j ACCEPT + fi # # Common ICMP rules # @@ -3907,23 +4017,25 @@ define_firewall() # $1 = Command (Start or Restart) process_rules $rules - echo "Setting up ICMP Echo handling..." + if [ -n "$OLD_PING_HANDLING" ]; then + echo "Setting up ICMP Echo handling..." - filterping_interfaces="`find_interfaces_by_option filterping`" - noping_interfaces="`find_interfaces_by_option noping`" + filterping_interfaces="`find_interfaces_by_option filterping`" + noping_interfaces="`find_interfaces_by_option noping`" - for interface in $all_interfaces; do - if ! list_search $interface $filterping_interfaces; then - if list_search $interface $noping_interfaces; then - target=DROP - else - target=ACCEPT + for interface in $all_interfaces; do + if ! list_search $interface $filterping_interfaces; then + if list_search $interface $noping_interfaces; then + target=DROP + else + target=ACCEPT + fi + + run_iptables -A `input_chain $interface` \ + -p icmp --icmp-type echo-request -j $target fi - - run_iptables -A `input_chain $interface` \ - -p icmp --icmp-type echo-request -j $target - fi - done + done + fi policy=`find_file policy` @@ -4161,15 +4273,15 @@ add_to_zone() # $1 = [:] $2 = zone rulenum=2 fi - if ! list_search $interface $filterping_interfaces; then + if list_search $interface $filterping_interfaces; then rulenum=$(($rulenum + 1)) fi - if ! list_search $interface $maclist_interfaces; then + if list_search $interface $maclist_interfaces; then rulenum=$(($rulenum + 1)) fi - if ! list_search $interface $tcpflags_interfaces; then + if list_search $interface $tcpflags_interfaces; then rulenum=$(($rulenum + 1)) fi @@ -4194,11 +4306,11 @@ add_to_zone() # $1 = [:] $2 = zone rulenum=2 fi - if ! list_search $interface $maclist_interfaces; then + if list_search $interface $maclist_interfaces; then rulenum=$(($rulenum + 1)) fi - if ! list_search $interface $tcpflags_interfaces; then + if list_search $interface $tcpflags_interfaces; then rulenum=$(($rulenum + 1)) fi fi @@ -4344,7 +4456,7 @@ delete_from_zone() # $1 = [:] $2 = zone while read z1 z2 chain; do if [ "$z1" = "$zone" ]; then if [ "$z2" = "$FW" ]; then - qt iptables -D `input_chain $interface` -i $interface -s $host -j $chain + qt iptables -D `input_chain $interface` -s $host -j $chain else source_chain=`forward_chain $interface` eval dest_hosts=\"\$${z2}_hosts\" @@ -4471,6 +4583,7 @@ do_initialize() { TCP_FLAGS_LOG_LEVEL= RFC1918_LOG_LEVEL= MARK_IN_FORWARD_CHAIN= + OLD_PING_HANDLING= SHARED_DIR=/usr/lib/shorewall FUNCTIONS= VERSION_FILE= @@ -4596,7 +4709,10 @@ do_initialize() { else CLEAR_TC= fi + OLD_PING_HANDLING=`added_param_value_yes OLD_PING_HANDLING $OLD_PING_HANDLING` + [ -z "$OLD_PING_HANDLING" -a -n "$FORWARDPING" ] && \ + startup_error "FORWARDPING=Yes is incompatible with OLD_PING_HANDLING=No" run_user_exit params diff --git a/STABLE/init.sh b/STABLE/init.sh index f775dfc32..464e7a75a 100644 --- a/STABLE/init.sh +++ b/STABLE/init.sh @@ -5,7 +5,7 @@ RCDLINKS="2,S41 3,S41 6,K41" # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # On most distributions, this file should be called: # /etc/rc.d/init.d/shorewall or /etc/init.d/shorewall diff --git a/STABLE/install.sh b/STABLE/install.sh index 53315b252..5429d1406 100755 --- a/STABLE/install.sh +++ b/STABLE/install.sh @@ -4,7 +4,7 @@ # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # Seawall documentation is available at http://seawall.sourceforge.net # @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.3.13 +VERSION=1.3.14 usage() # $1 = exit status { diff --git a/STABLE/interfaces b/STABLE/interfaces index 595d49581..29490d9b5 100644 --- a/STABLE/interfaces +++ b/STABLE/interfaces @@ -46,18 +46,6 @@ # a DHCP server running on the firewall or # you have a static IP but are on a LAN # segment with lots of Laptop DHCP clients. -# noping - icmp echo-request (ping) packets -# addressed to the firewall should -# be ignored on this interface -# filterping - icmp echo-request (ping) packets -# addressed to the firewall should -# be controlled by the rules file and -# applicable policy. If neither 'noping' -# nor 'filterping' are specified then -# the firewall will respond to 'ping' -# requests. 'filterping' takes -# precedence over 'noping' if both are -# given. # routestopped - (Deprecated -- use # /etc/shorewall/routestopped) # When the firewall is stopped, allow @@ -117,29 +105,28 @@ # eth1 connected to your local network and that your # local subnet is 192.168.1.0/24. The interface gets # it's IP address via DHCP from subnet -# 206.191.149.192/27 and you want pings from the internet -# to be ignored. You interface a DMZ with subnet +# 206.191.149.192/27. You have a DMZ with subnet # 192.168.2.0/24 using eth2. You want to be able to # access the firewall from the local network when the # firewall is stopped. # # Your entries for this setup would look like: # -# net eth0 206.191.149.223 noping,dhcp +# net eth0 206.191.149.223 dhcp # local eth1 192.168.1.255 routestopped # dmz eth2 192.168.2.255 # # Example 2: The same configuration without specifying broadcast # addresses is: # -# net eth0 detect noping,dhcp +# net eth0 detect dhcp # loc eth1 detect routestopped # dmz eth2 detect # # Example 3: You have a simple dial-in system with no ethernet -# connections and you want to ignore ping requests. +# connections. # -# net ppp0 - noping +# net ppp0 - ############################################################################## #ZONE INTERFACE BROADCAST OPTIONS #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE diff --git a/STABLE/masq b/STABLE/masq index 3b0edea3e..0b8515619 100644 --- a/STABLE/masq +++ b/STABLE/masq @@ -9,7 +9,15 @@ # Columns are: # # INTERFACE -- Outgoing interface. This is usually your internet -# interface. This may be qualified by adding the character +# interface. If ADD_SNAT_ALIASES=Yes in +# /etc/shorewall/shorewall.conf, you may add ":" and +# a digit to indicate that you want the alias added with +# that name (e.g., eth0:0). This will allow the alias to +# be displayed with ifconfig. THAT IS THE ONLY USE FOR +# THE ALIAS NAME AND IT MAY NOT APPEAR IN ANY OTHER +# PLACE IN YOUR SHOREWALL CONFIGURATION. +# +# This may be qualified by adding the character # ":" followed by a destination host or subnet. # # @@ -17,7 +25,7 @@ # a subnet or as an interface. If you give the name of an # interface, you must have iproute installed and the interface # must be up before you start the firewall. -# +# # In order to exclude a subset of the specified SUBNET, you # may append "!" and a comma-separated list of IP addresses # and/or subnets that you wish to exclude. @@ -74,13 +82,12 @@ # Example 4: # # You want all outgoing traffic from 192.168.1.0/24 through -# eth0 to use source address 206.124.146.176. +# eth0 to use source address 206.124.146.176 which is NOT the +# primary address of eth0. You want 206.124.146.176 added to +# be added to eth0 with name eth0:0. # -# eth0 192.168.1.0/24 206.124.146.176 +# eth0:0 192.168.1.0/24 206.124.146.176 # -# This would normally be done when you have a static external -# IP address since it makes the processing of outgoing -# packets somewhat faster. ############################################################################## #INTERFACE SUBNET ADDRESS #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE diff --git a/STABLE/nat b/STABLE/nat index 7b6ba5b20..e791a8052 100644 --- a/STABLE/nat +++ b/STABLE/nat @@ -16,7 +16,13 @@ # IP address of the interface named in the next # column and must not be a DNS Name. # INTERFACE Interface that we want to EXTERNAL address to appear -# on +# on. If ADD_IP_ALIASES=Yes in shorewall.conf, you may +# follow the interface name with ":" and a digit to +# indicate that you want Shorewall to add the alias +# with this name (e.g., "eth0:0"). That allows you to +# see the alias with ifconfig. THAT IS THE ONLY THING +# THAT THIS NAME IS GOOD FOR -- YOU CANNOT USE IT +# ANYWHERE ELSE IN YOUR SHORWALL CONFIGURATION. # INTERNAL Internal Address (must not be a DNS Name). # 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 @@ -26,5 +32,5 @@ # Yes or yes, NAT will be effective from the firewall # system ############################################################################## -#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL +#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE diff --git a/STABLE/releasenotes.txt b/STABLE/releasenotes.txt index f9f09cad3..1770be3ea 100644 --- a/STABLE/releasenotes.txt +++ b/STABLE/releasenotes.txt @@ -2,48 +2,104 @@ This is a minor release of Shorewall that has a couple of new features. New features include: -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. +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 + option in shorewall.conf is ignored and the 'noping' and + 'filterping' options in /etc/shorewall/interfaces will generate an + error. + +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) The ability to name your VLAN interfaces using the $dev.$vid + convention (e.g., "eth0.0") has been restored. This capability was + inadvertently broken in version 1.3.12. + +4) Support has been added for defining OpenVPN tunnels in the + /etc/shorewall/tunnels file. + +5) 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. - 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: + [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 - 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,... + [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]# 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... - These three rules ended up generating _three_ copies of + 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. - ACCEPT net dmz:206.124.146.177 tcp smtp + 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]# - By writing the rules this way, I end up with only one copy of the - ACCEPT rule. + In this case, the second entry in /etc/shorewall/masq is no longer + required. - 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,... + Example 3 -- What if your current configuration is like this? -2) The 'shorewall check' command now prints out the applicable policy - between each pair of zones. + [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]# -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. + In this case, you would want to change the entry in + /etc/shorewall/masq to: -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. + #INTERFACE SUBNET ADDRESS + eth0 192.168.1.0/24 206.124.146.176 + #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE diff --git a/STABLE/shorewall b/STABLE/shorewall index 8b0e6b04f..3a2da0b91 100755 --- a/STABLE/shorewall +++ b/STABLE/shorewall @@ -4,7 +4,7 @@ # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # # This file should be placed in /sbin/shorewall. @@ -649,7 +649,7 @@ case "$1" in [ $# -ne 3 ] && usage 1 exec $FIREWALL $debugging $nolock $1 $2 $3 ;; - show) + show|list) [ $# -gt 2 ] && usage 1 case "$2" in connections) diff --git a/STABLE/shorewall.conf b/STABLE/shorewall.conf index 5d6c3e8a5..b79bb1faf 100644 --- a/STABLE/shorewall.conf +++ b/STABLE/shorewall.conf @@ -6,7 +6,7 @@ # # This file should be placed in /etc/shorewall # -# (c) 1999,2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) ############################################################################## # # You should not have to change the variables in this section -- they are set @@ -401,12 +401,17 @@ MUTEX_TIMEOUT=60 LOGNEWNOTSYN= # -# Forward "Ping" +# Old Ping Handling # -# If FORWARDPING is set to "Yes" then Echo Request ("Ping") packets are -# forwarded by the firewall. - -FORWARDPING=Yes +# If this option is set to "Yes" then Shorewall will use its old ping handling +# facility including the FORWARDPING option in this file and the 'noping' and +# 'filterping' interface options. If this option is set to 'No' then ping +# is handled via policy and rules just like any other connection request. +# +# If you are a new Shorewall user DON'T CHANGE THE VALUE OF THIS OPTION AND +# DON'T DELETE IT!!!!!! +# +OLD_PING_HANDLING=No # # NEWNOTSYN diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index e77c3cbf2..2be4d6efe 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.3.13 +%define version 1.3.14 %define release 1 %define prefix /usr @@ -105,6 +105,14 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Fri Feb 07 2003 Tom Eastep +- Changes version to 1.3.14-1 +* Tue Feb 04 2003 Tom Eastep +- Changes version to 1.3.14-0RC1 +* Tue Jan 28 2003 Tom Eastep +- Changes version to 1.3.14-0Beta2 +* Sat Jan 25 2003 Tom Eastep +- Changes version to 1.3.14-0Beta1 * Mon Jan 13 2003 Tom Eastep - Changes version to 1.3.13 * Fri Dec 27 2002 Tom Eastep diff --git a/STABLE/tcrules b/STABLE/tcrules index d905a01ab..41d23120b 100644 --- a/STABLE/tcrules +++ b/STABLE/tcrules @@ -17,10 +17,20 @@ # MARK The mark value which is an # integer in the range 1-255 # +# May optionally be followed by ":P" or ":F" +# where ":P" indicates that marking should occur in +# the PREROUTING chain and ":F" indicates that marking +# should occur in the FORWARD chain. If neither +# ":P" nor ":F" follow the mark value then the chain is +# determined by the setting of MARK_IN_FORWARD_CHAIN in +# /etc/shorewall/shorewall.conf. +# # SOURCE Source of the packet. A comma-separated list of # interface names, IP addresses, MAC addresses # and/or subnets. Use $FW if the packet originates on -# the firewall. +# the firewall in which case the MARK column may NOT +# specify either ":P" or ":F" (marking always occurs +# in the OUTPUT chain). # # MAC addresses must be prefixed with "~" and use # "-" as a separator. diff --git a/STABLE/tunnel b/STABLE/tunnel index 12b26523d..6fd56fad7 100644 --- a/STABLE/tunnel +++ b/STABLE/tunnel @@ -9,7 +9,7 @@ RCDLINKS="2,S45 3,S45 6,K45" # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # Modify the following variables to match your configuration # diff --git a/STABLE/tunnels b/STABLE/tunnels index 5e961d6fd..86747729b 100644 --- a/STABLE/tunnels +++ b/STABLE/tunnels @@ -1,16 +1,21 @@ # # Shorewall 1.3 - /etc/shorewall/tunnels # -# This file defines IPSEC, GRE and IPIP tunnels. +# This file defines IPSEC, GRE, IPIP and OPENVPN tunnels. # -# IPIP and GRE tunnels must be configured on the firewall/gateway itself. -# IPSEC endpoints may be defined on the firewall/gateway or on an -# internal system. +# IPIP, GRE and OPENVPN tunnels must be configured on the +# firewall/gateway itself. IPSEC endpoints may be defined +# on the firewall/gateway or on an internal system. # # The columns are: # # TYPE -- must start in column 1 and be "ipsec", "ipsecnat","ip" -# "gre","pptpclient" or "pptpserver" +# "gre", "pptpclient", "pptpserver" or "openvpn". +# +# If type is "openvpn", it may optionally be followed +# by ":" and the port number used by the tunnel. if no +# ":" and port number are included, then the default port +# of 5000 will be used # # ZONE -- The zone of the physical interface through which # tunnel traffic passes. This is normally your internet @@ -20,10 +25,12 @@ # remote getway has no fixed address (Road Warrior) # then specify the gateway as 0.0.0.0/0. # -# GATEWAY ZONES -- Optional. If the gateway system specified in the third +# GATEWAY +# ZONES -- Optional. If the gateway system specified in the third # column is a standalone host then this column should -# contain a comma-separated list of the names of the zones that -# the host might be in. This column only applies to IPSEC tunnels. +# contain a comma-separated list of the names of the +# zones that the host might be in. This column only +# applies to IPSEC tunnels. # # Example 1: # @@ -71,5 +78,12 @@ # # pptpserver net # -# TYPE ZONE GATEWAY GATEWAY ZONE +# Example 7: +# +# OPENVPN tunnel. The remote gateway is 4.33.99.124 and +# openvpn uses port 7777. +# +# openvpn:7777 net 4.33.99.124 +# +# TYPE ZONE GATEWAY GATEWAY ZONE PORT #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index c4d83c1fa..510f4e14f 100755 --- a/STABLE/uninstall.sh +++ b/STABLE/uninstall.sh @@ -4,7 +4,7 @@ # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # -# (c) 2000,2001,2002 - Tom Eastep (teastep@shorewall.net) +# (c) 2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # Shorewall documentation is available at http://shorewall.sourceforge.net # @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=1.3.13 +VERSION=1.3.14 usage() # $1 = exit status {