From 73d5757eafa6c32a83bc1368de448f15cd99948c Mon Sep 17 00:00:00 2001 From: teastep Date: Fri, 28 Jan 2005 03:07:21 +0000 Subject: [PATCH] Some 2.2.0 Updates git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1928 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-Website/News.htm | 124 +++- Shorewall-Website/download.htm | 18 +- Shorewall-Website/shoreline.htm | 15 +- Shorewall-Website/shorewall_index.htm | 810 ++++++++++++++++++++++---- 4 files changed, 835 insertions(+), 132 deletions(-) diff --git a/Shorewall-Website/News.htm b/Shorewall-Website/News.htm index 03c7fe2a4..ca8ceef97 100644 --- a/Shorewall-Website/News.htm +++ b/Shorewall-Website/News.htm @@ -18,11 +18,131 @@ Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

-

2005-01-04
+

2005-02-01


-12/24/2004 - +01/17/2005 - +Shorewall 2.2.0 RC5
+
+Problems Corrected:
+

+
    +
  1. The AllowTrcrt action has been changed to allow up to 30 hops +(same as default for 'traceroute'). Previously, the action was +documented as allowing 20 hops but actually only allowed for 6 hops.
    +
    2. +
  2. Using some lightweight shells, valid entries in +/etc/shorewall/ecn produce startup errors.
    3. +
+New Features:
+
    +
  1. A new AllowInvalid standard built-in action has been added. This +action accepts packets that are in the INVALID connection-tracking +state.
    2. +
+01/16/2005 - New +Shorewall Mirrors
+
+Thanks to Lorenzo Martignoni and Nick Slikey, there are now +Shorewall mirrors in Milan Italy +and in Austin Texas. Thanks Lorenzo +and Nick!
+
+01/12/2005 - +Shorewall 2.0.15
+
+Problems Corrected:
+
    +
  1. The range of ports opened by the AllowTrcrt action has been +expanded to 33434:33524 to allow for a maximum of 30 hops.
    2. +
  2. Code mis-ported from 2.2.0 in release 2.0.14 caused the following +error during "shorewall start" where SYN rate-limiting is present in +/etc/shorewall/policy:
    + 
    +      Bad argument `DROP'
    +      Try `iptables -h' or 'iptables --help' +for more information.
    +
    3. +
+01/06/2005 - +Shorewall 2.2.0 RC4
+
+New Features:
+
    +
  1. A listing of loaded iptables kernel modules is now included in +the output of "shorewall status".
    +
    2. +
+Problems Corrected.
+
    +
  1. Several problems associated with processing the IPSEC colummn in +/etc/shorewall/masq have been corrected.
    +
    2. +
+01/03/2005 - +Shorewall 2.0.14
+
+New Features:
+
    +
  1. Previously, when rate-limiting was specified in +/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded +the specified rate was silently dropped. Now, if a log level is given +in the entry (LEVEL column) then drops are logged at that level at a +rate of 5/min with a burst of 5.
    +
    2. +
+Problems Corrected:
+
    +
  1. A typo in the /etc/shorewall/interfaces file has been fixed.
    2. +
  2. "bad variable" error messages occurring during "shorewall stop" +and "shorewall clear" have been eliminated.
    3. +
  3. A misleading typo in /etc/shorewall/tunnels has been corrected. +The TYPE column for an IPIP tunnel should contain "ipip" rather than +"ip".
    +
    4. +
+12/31/2004 +- Mandrake-specific RPMs available
+
+Jack Coates has generously volunteered to provide Shorewall RPMs +for use under Mandrake. You can download Jack's RPMs from http://www.monkeynoodle.org/tmp/
+
+12/31/2004 +- Redhat/Fedora-specific RPMs available
+
+Simon Matter has graciously volunteered to provide RPMs taylored for +Redhat and Fedora. You can download Simon's RPMs from http://www.invoca.ch/pub/packages/shorewall/
+
+Thanks, Simon!
+
+12/30/2004 - +Shorewall 2.2.0 RC3
+
+Problems Corrected:
+
    +
  1. The following error message could appear during "shorewall stop" +or "shorewall clear":
    +                                                                                                                                                                                                                 +
    +              +local: lo:: bad variable name
    +
    +
    2. +
  2. The rate limiting example in /etc/shorewall/rules has been +changed to use the RATE LIMIT column.
    3. +
  3. Entries in /etc/shorewall/masq with the INTERFACE column +containing <ifname>:: (e.g., "eth0::") would generate a progress +message but would not generate an iptables rule.
    4. +
  4. A misleading typo in /etc/shorewall/tunnels has been corrected.
    +
    5. +
+ +


+

+

12/24/2004 - Shorewall 2.2.0 RC2

New Features:
diff --git a/Shorewall-Website/download.htm b/Shorewall-Website/download.htm index 1d0c7497f..86d9616c8 100644 --- a/Shorewall-Website/download.htm +++ b/Shorewall-Website/download.htm @@ -22,7 +22,7 @@ Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

-

2005-01-14
+

2005-01-26

I strongly urge you to read and print a copy of the of the modules:

his site.
  • Jack Coates provides RPMs taylored for Mandrake. You can download them from his site.
    + href="http://www.monkeynoodle.org/tmp">download them from his site.
    • +
  • Marc Zonzon provides a package for OpenWRT (Open firmware for Linksys® +WRT54G). You can download +it from his site.
  • If you run a SuSE, Linux PPC, Trustix or @@ -72,7 +77,10 @@ use the standard RPM version (note: the RPM should also work with other distributions that store init scripts in /etc/init.d and that include chkconfig or insserv). If you find that it works in other cases, let me know so that I can mention -them here. See the Installation Instructions +them here (Note: the standard RPM is known to work on Redhat, Fedora +and Mandrake with issues ranging from trivial (Redhat and Fedora) to +moderate (Mandrake)). See the Installation +Instructions if you have problems installing the RPM.
  • If you are running LEAF Bering or Bering uClibc, download the .lrp file
    @@ -106,6 +114,10 @@ Simon Matter: http://www.
    Mandrake RPMS provided by Jack Coates:     http://www.monkeynoodle.org/tmp
    +
    +OpenWRT package provided by +Marc Zonzon: http://www.iut-lannion.fr/ZONZON/memos_index.php?part=Network&section=WRTMemo&subsec=shorewall
    diff --git a/Shorewall-Website/shoreline.htm b/Shorewall-Website/shoreline.htm index c9d74adb8..60d1b1af0 100644 --- a/Shorewall-Website/shoreline.htm +++ b/Shorewall-Website/shoreline.htm @@ -15,9 +15,17 @@ when there is nothing left to add, but rather when there is nothing left to take away.

     - Antoine de Saint-Exupery
    +

    +Fragmentation is like classful +addressing -- an interesting early architectural error that shows how +much experimentation was going on while IP was being designed.
    +

    +- Paul Vixie
    +
    +

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

    Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version @@ -27,11 +35,12 @@ Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

    -

    2004-11-18
    +

    2005-01-24

    Aging Geek - June 2003

    + alt="Aging Geek - June 2003" + style="border: 3px solid ; width: 320px; height: 240px;">

    "The Aging Geek" -- June 2003


    diff --git a/Shorewall-Website/shorewall_index.htm b/Shorewall-Website/shorewall_index.htm index 5b23667bc..9e48b2acd 100644 --- a/Shorewall-Website/shorewall_index.htm +++ b/Shorewall-Website/shorewall_index.htm @@ -28,20 +28,16 @@ to 2.x releases of Shorewall. For older versions:

    target="_top">here.

    -

    The current 2.0 Stable Release is 2.0.15 -- Here are the release -notes.
    -The current Developement Release is 2.2.0 RC5 -- Here -are the release +

    The current 2.2 Stable Release is 2.2.0 -- Here are the release notes and here are the known + href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.0/known_problems.txt">known problems.

    Preparing for Shorewall 2.2 -- End of -support life for Shorewall 1.4 is Near!
    + style="font-weight: bold;">End of +support life for Shorewall 1.4 -- Upgrading to Shorewall 2.2

    Copyright © 2001-2005 Thomas M. Eastep

    Permission is granted to copy, distribute and/or modify this @@ -51,7 +47,7 @@ Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

    -

    2005-01-17

    +

    2005-02-01

    Table of Contents

    Introduction @@ -66,23 +62,14 @@ Shorewall
    Shorewall on Mandrake® with a two-interface setup?
    License

    News

    -

    Shorewall -2.2.0-RC5
    -New -Shorewall Mirrors
    -Shorewall -2.0.15
    -Shorewall -2.2.0-RC4
    -Shorewall -2.0.14
    -Mandrake-specific RPMs available
    -Redhat/Fedora-specific RPMs available
    -Shorewall -2.2.0 RC3
    +

    Shorewall +2.2.0

    Donations

    Introduction to Shorewall

    @@ -171,123 +158,690 @@ of the license is included in the section entitled "GNU Free Documentation License".

    News

    -01/17/2005 - -Shorewall 2.2.0 RC5
    +02/01/2005 +Shorewall 2.2.0

    -    Problems Corrected:
    +    New Features:
      -
    1. The AllowTrcrt action has been changed to allow up to 30 hops -(same as default for 'traceroute'). Previously, the action was -documented as allowing 20 hops but actually only allowed for 6 hops.
      +
    2. ICMP packets that are in the INVALID state are now dropped by the +Reject and Drop default actions. They do so using the new 'dropInvalid' +builtin action. An 'allowInvalid' builtin action is also provided which +accepts packets in that state.
      3. +
    3. The /etc/shorewall/masq file INTERFACE column now allows +additional options.
      +
      +Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules +defined in the /etc/shorewall/nat file. If you preceed the interface +name with a plus sign ("+") then the rule will be evaluated before +one-to-one NAT.
      +
      +Examples:
      +
      ++eth0
      ++eth1:192.0.2.32/27
      +
      +Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by +following the interface name by ":" but no digit.
      +
      +Examples:
      +
      +eth0:
      +eth1::192.0.2.32/27
      ++eth3:
      +
      4. -
    4. Using some lightweight shells, valid entries in -/etc/shorewall/ecn produce startup errors.
      5. +
    5. Similar to 2), the /etc/shorewall/nat file INTERFACE column now +allows you to override the setting of ADD_IP_ALIASES=Yes by following +the interface name with ":" but no digit.
      6. +
    6. All configuration files in the Shorewall distribution with the +exception of shorewall.conf are now empty. In particular, the +/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos +files now have no active entries. Hopefully this will stop the +questions on the support and development lists regarding why the +default entries are the way they are.
      7. +
    7. Previously, including a log level (and optionally a log tag) on a +rule that specified a user-defined (or Shorewall-defined) action would +log all traffic passed to the action. Beginning with this release, +specifying a log level in a rule that specifies a user- or +Shorewall-defined action will cause each rule in the action to be +logged with the specified level (and tag).
      +
      +The extent to which logging of action rules occurs is goverend by the +following:
      8. +
        +
      • When you invoke an action and specify a log level, only those +rules in the action that have no log level will be changed to log at +the level specified at the action invocation.
        +
        +Example:
        +
        +/etc/shorewall/action.foo:
        +
        +ACCEPT    -    -    +tcp    22
        +bar:info
        +
        +/etc/shorewall/rules:
        +
        +foo:debug    fw    net
        +
        +Logging in the invoked 'foo' action will be:
        +
        +ACCEPT:debug    -    -    +tcp    22
        +bar:info
        +
        +
        • +
      • If you follow the log level with "!" then logging will be at +that level for all rules recursively invoked by the action
        +
        +Example: /etc/shorewall/action.foo:
        +
        +ACCEPT    -    -    +tcp    22
        +bar:info
        +
        +/etc/shorewall/rules:
        +
        +foo:debug!    fw    net
        +
        +Logging in the invoke 'foo' action will be:
        +
        +ACCEPT:debug    -    -    +tcp    22
        +bar:debug!
        +
        +
        • +
    -New Features:
    -
      -
    1. A new AllowInvalid standard built-in action has been added. This -action accepts packets that are in the INVALID connection-tracking -state.
      2. -
    -01/16/2005 - New -Shorewall Mirrors
    +
    This change has an effect on extension +scripts used with user-defined actions. If you define an action 'acton' +and you have an /etc/shorewall/acton script then when that script is +invoked, the following three variables will be set for use by the +script:

    -Thanks to Lorenzo Martignoni and Nick Slikey, there are now -Shorewall mirrors in Milan Italy -and in Austin Texas. Thanks Lorenzo -and Nick!
    -
    -01/12/2005 - -Shorewall 2.0.15
    -
    -Problems Corrected:
    -
      -
    1. The range of ports opened by the AllowTrcrt action has been -expanded to 33434:33524 to allow for a maximum of 30 hops.
      2. -
    2. Code mis-ported from 2.2.0 in release 2.0.14 caused the following -error during "shorewall start" where SYN rate-limiting is present in -/etc/shorewall/policy:
      - 
      -      Bad argument `DROP'
      -      Try `iptables -h' or 'iptables --help' -for more information.
      -
      3. +
      $CHAIN = the name of the chain where +your rules are to be placed. When logging is used on an action +invocation, Shorewall creates a chain with a slightly different name +from the action itself.
      +$LEVEL = Log level. If empty, no logging was specified.
      +$TAG   = Log Tag.
      +
      +
      +Example:
      +
      +/etc/shorewall/rules:
      +   
      +acton:info:test
      +
      +Your /etc/shorewall/acton file will be run with:
      +
      +
      $CHAIN="%acton1
      +$LEVEL="info"
      +$TAG="test"
      +
      +
    +
    +
      +
    1. The /etc/shorewall/startup_disabled file is no longer created +when +Shorewall is first installed. Rather, the variable STARTUP_ENABLED is +set to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall +to start, that variable's value must be set to 'Yes'. This change +accomplishes two things:
      2. +
        +
      • It prevents Shorewall from being started prematurely by the +user's initialization scripts.
        • +
      • It causes /etc/shorewall/shorewall.conf to be modified so that +it won't be replaced by upgrades using RPM.
        +
        +
        • +
      +
    2. Support has been added for the 2.6 Kernel IPSEC implementation. +To use this support, you must have installed the IPSEC policy match +patch and the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The +policy match patch affects both your kernel and iptables. There are two +ways to specify that IPSEC is to be used when communicating with a set +of hosts; both methods involve the new /etc/shorewall/ipsec file:
      3. +
        +
      1. If encrypted communication is used with all hosts in a zone, +then you can designate the zone as an "ipsec" zone by placing 'Yes" in +the IPSEC ONLY column in /etc/shorewall/ipsec:
        +
        + #ZONE    +    IPSEC    OPTIONS ...
        + #    +        ONLY
        + vpn    +      Yes
        +
        +The hosts in the zone (if any) must be specified in +/etc/shorewall/hosts but you do not need to specify the 'ipsec' option +on the entries in that file (see below). Dynamic zones involving IPSEC +must use that technique.
        +
        +Example:Under 2.4 Kernel FreeS/Wan:
        +
        +/etc/shorewall/zones:
        +
        + net    +Net    The big bad Internet
        + vpn    +VPN    Remote Network
        +
        +/etc/shorewall/interfaces:
        +
        + net    +eth0    ...
        + vpn    +ipsec0    ...
        +
        +Under 2.6 Kernel with this new support:
        +
        +/etc/shorewall/zones:
        +
        + net    +Net    The big bad Internet
        + vpn    +VPN    Remote Network
        +
        +/etc/shorewall/interfaces:
        +
        + net    +eth0    ...
        +
        +/etc/shorewall/hosts:
        +
        + vpn    +eth0:0.0.0.0/0
        +
        +/etc/shorewall/ipsec
        +
        + vpn    Yes
        +
        +
        2. +
      2. If only part of the hosts in a zone require encrypted +communication, you may use of the new 'ipsec' option in +/etc/shorewall/hosts to designate those hosts.
        +
        +Example:
        +
        +Under 2.4 Kernel FreeS/Wan:
        +
        +/etc/shorewall/zones:
        + 
        net    Net    The big bad Internet
        loc    Local  Extended local zone
        +/etc/shorewall/interfaces:
        +
        + net    +eth0    ...
        + loc    +eth1    ...
        + loc    +ipsec0    ...
        +
        +Under 2.6 Kernel with this new support:
        +
        +/etc/shorewall/zones:
        +
        + net    +    Net    The big bad Internet
        + vpn      +  VPN    Remote Network
        +
        +/etc/shorewall/interfaces:
        +
        + net    +eth0    ...
        + loc    +eth1    ...
        +
        +/etc/shorewall/hosts:
        +
        + vpn    +eth0:0.0.0.0/0    ipsec,...
        3. +
    -01/06/2005 - -Shorewall 2.2.0 RC4
    -
    -New Features:
    -
      -
    1. A listing of loaded iptables kernel modules is now included in -the output of "shorewall status".
      +
      Regardless of which technique you +choose, you can specify additional SA options for the zone in the +/etc/shorewall/ipsec entry.
      +
      +The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the +input-output, input and output characteristics of the security +associations to be used to decrypt (input) or encrypt (output) traffic +to/from the zone.
      +
      +The available options are:
      +
      +
        +
          +
        • reqid[!]=<number> where <number> is specified using +setkey(8) using the 'unique:<number>' option for the SPD level.
          • +
        • spi[!]=<number> where <number> is the SPI of the +SA. Since different SAs are used to encrypt and decrypt traffic, this +option should only be listed in the IN OPTIONS and OUT OPTIONS columns.
          • +
        • proto[!]=ah|esp|ipcomp
          • +
        • mss=<number> (sets the MSS value in TCP SYN packets and +is not related to policy matching)
          • +
        • mode[!]=transport|tunnel
          • +
        • tunnel-src[!]=<address>[/<mask>] (only available +with mode=tunnel)
          • +
        • tunnel-dst[!]=<address>[/<mask>] (only available +with mode=tunnel). Because tunnel source and destination are dependent +on the direction of the traffic, these options should only appear in +the IN OPTIONS and OUT OPTIONS columns.
          • +
        • strict  (if specified, packets must match all policies; +policies are delimited by 'next').
          • +
        • next    (only available with strict)
          • +
        +
      +
      Examples:
      +
      +#ZONE    +IPSEC  OPTIONS        +          +IN    +      OUT
      +#        +ONLY            +                +OPTIONS     OPTIONS
      +vpn      +Yes    mode=tunnel,proto=esp    +spi=1000    spi=1001
      +loc      +No     reqid=44,mode=transport
      +
      +The /etc/shorewall/masq file has a new IPSEC column added. If you +specify Yes or yes in that column then the unencrypted packets will +have their source address changed. Otherwise, the unencrypted packets +will not have their source addresses changed. This column may also +contain a comma-separated list of the options specified above in which +case only those packets that will be encrypted by an SA matching the +given options will have their source address changed.
      +
      +
        +
      1. To improve interoperability, tunnels of type 'ipsec' no longer +enforce the use of source port 500 for ISAKMP and OpenVPN tunnels no +longer enforce use of the specified port as both the source and +destination ports.
        2. +
      2. A new 'allowBcast' builtin action has been added -- it silently +allows broadcasts and multicasts.
        3. +
      3. The -c option in /sbin/shorewall commands is now deprecated. The +commands where -c was previously allowed now permit you to specify a +configuration directory after the command:
        +
        +      shorewall check   [ +<configuration-directory> ]
        +      shorewall restart [ +<configuration-directory> ]
        +      shorewall start   [ +<configuration-directory> ]
        +
        4. -
      -Problems Corrected.
      -
        -
      1. Several problems associated with processing the IPSEC colummn in -/etc/shorewall/masq have been corrected.
        +
      2. Normally, when SNAT or MASQUERADE is applied to a tcp or udp +connection, Netfilter attempts to retain the source port number. If it +has to change to port number to avoid  <source +address>,<source port> conflicts, it tries to do so within +port ranges ( < 512, 512-1023, and > 1023). You may now specify +an explicit range of source ports to be used by following the address +or address range (if any) in the ADDRESS column with ":" and a port +range in the format <low-port>-<high-port>. You must +specify either "tcp" or "udp" in the PROTO column.
        +
        +Examples 1 -- MASQUERADE with tcp source ports 4000-5000:
        +
        +     #INTERFACE +SUBNET          +ADDRESS        PROTO
        +     +eth0       192.168.1.0/24  +:4000-5000     tcp
        +
        +Example 2 -- SNAT with udp source ports 7000-8000:
        +
        +    #INTERFACE +SUBNET          +ADDRESS    +             +PROTO
        +    +eth0       +10.0.0.0/8      +192.0.2.44:7000-8000    udp
        +
        +
        3. +
      3. You may now account by user/group ID for outbound traffic from +the firewall itself with entries in /etc/shorewall/accounting. Such +accounting rules must be placed in the OUTPUT chain. See the comments +at the top of /etc/shorewall/accounting for details.
        4. +
      4. Shorewall now verifies that your kernel and iptables have physdev +match support if BRIDGING=Yes in shorewall.conf.
        5. +
      5. Beginning with this release, if your kernel and iptables have +iprange match support (see the output from "shorewall check"), then +with the exception of the /etc/shorewall/netmap file, anywhere that a +network address may appear an IP address range of the form <low +address>-<high address> may also appear.
        6. +
      6. Support has been added for the iptables CLASSIFY target. That +target allows you to classify packets for traffic shaping directly +rather than indirectly through fwmark. Simply enter the +<major>:<minor> classification in the first column of +/etc/shorewall/tcrules:
        +
        +Example:
        +
        + #MARK/      +SOURCE       +DEST      PROTO     PORT(S)
        + #CLASSIFY
        + 1:30    +    -        +    eth0      tcp    +   25
        +
        +Note that when using this form of rule, it is acceptable to include the +name of an interface in the DEST column.
        +
        +Marking using the CLASSIFY target always occurs in the POSTROUTING +chain of the mangle table and is not affected by the setting of +MARK_IN_FORWARD_CHAIN in shorewall.conf.
        7. +
      7. During "shorewall start", IP addresses to be added as a +consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly +deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed +then they are re-added later. This is done to help ensure that the +addresses can be added with the specified labels but can have the +undesirable side effect of causing routes to be quietly deleted. A new +RETAIN_ALIASES option has been added to shorewall.conf; when this +option is set to Yes, existing addresses will not be deleted. +Regardless of the setting of RETAIN_ALIASES, addresses added during +"shorewall start" are still deleted at a subsequent "shorewall stop" or +"shorewall restart".
        8. +
      8. Users with a large black list (from /etc/shorewall/blacklist) may +want to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When +DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before +loading the blacklist rules. While this may allow connections from +blacklisted hosts to slip by during construction of the blacklist, it +can substantially reduce the time that all new connections are disabled +during "shorewall [re]start".
        9. +
      9. Using the default LOGFORMAT, chain names longer than 11 +characters (such as in user-defined actions) may result in log prefix +truncation. A new shorewall.conf action  LOGTAGONLY has been added +to deal with this problem. When LOGTAGONLY=Yes, logging rules that +specify a log tag will substitute the tag for the chain name in the log +prefix.
        +
        +Example -- file /etc/shorewall/action.thisisaverylogactionname:
        +
        +    Rule:
        +
        +         DROP:info:ftp    +0.0.0.0/0    0.0.0.0/0    +tcp        21
        +   
        +    Log prefix with LOGTAGONLY=No:
        +
        +         Shorewall:thisisaverylongacti
        +
        +    Log prefix with LOGTAGONLY=Yes:
        +
        +         Shorewall:ftp:DROP
        +
        10. -
      -01/03/2005 - -Shorewall 2.0.14
      -
      -New Features:
      -
        +
      1. Shorewall now resets the 'accept_source_route' flag for all +interfaces. If you wish to accept source routing on an interface, you +must specify the new 'sourceroute' interface option in +/etc/shorewall/interfaces.
        2. +
      2. The default Drop and Reject actions now invoke the new standard +action 'AllowICMPs'. This new action accepts critical ICMP types:
        +   
        +    Type 3 code 4 (fragmentation needed)
        +    Type 11       (TTL +exceeded)
        +
        +
        3. +
      3. Explicit control over the kernel's Martian logging is now +provided using the new 'logmartians' interface option. If you include +'logmartians' in the interface option list then logging of Martian +packets on will be enabled on the specified interface. If you wish to +globally enable martian logging, you can set LOG_MARTIANS=Yes in +shorewall.conf.
        4. +
      4. You may now cause Shorewall to use the '--set-mss' option of the +TCPMSS target. In other words, you can cause Shorewall to set the MSS +field of SYN packets passing through the firewall to the value you +specify. This feature extends the existing CLAMPMSS option in +/etc/shorewall/shorewall.conf by allowing that option to have a numeric +value as well as the values "Yes" and "No".
        +
        +Example:
        +
        +    CLAMPMSS=1400
        +
        +
        5. +
      5. Shorewall now includes support for the ipp2p match facility. This +is a departure from my usual policy in that the ipp2p match facility is +included in Patch-O-Matic-NG and is unlikely to ever be included in the +kernel.org source tree. Questions about how to install the patch or how +to build your kernel and/or iptables should not be posted on the +Shorewall mailing lists.
        +
        +In the following files, the "PROTO" or "PROTOCOL" column may contain +"ipp2p":
        +
        +       /etc/shorewall/rules
        +       /etc/shorewall/tcrules
        +       /etc/shorewall/accounting
        +
        +When the PROTO or PROTOCOL column contains "ipp2p" then the DEST +PORT(S) or PORT(S) column may contain a recognized ipp2p option; for a +list of the options and their meaning, at a root prompt:
        +
        +    iptables -m ipp2p --help
        +
        +You must not include the leading "--" on the option; Shorewall will +supply those characters for you. If you do not include an option then +"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").
        6. +
      6. Shorewall now has support for the CONNMARK target from iptables. +See the /etc/shorewall/tcrules file for details.
        7. +
      7. A new debugging option LOGALLNEW has been added to +shorewall.conf. When set to a log level, this option causes Shorewall +to generaate a logging rule as the first rule in each builtin chain.
        +
        +    - The table name is used as the chain name in the +log prefix.
        +    - The chain name is used as the target in the log +prefix.
        +
        +Example: Using the default LOGFORMAT, the log prefix for logging from +the nat table's PREROUTING chain is:
        +
        +     Shorewall:nat:PREROUTING
        +
        +IMPORTANT: There is no rate limiting on these logging rules so use +LOGALLNEW at your own risk; it may cause high CPU and disk utilization +and you may not be able to control your firewall after you enable this +option.
        +
        +DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE +SENT TO ANOTHER SYSTEM.
        +
        +
        8. +
      8. The SUBNET column in /etc/shorewall/rfc1918 has been renamed +SUBNETS and it is now possible to specify a list of addresses in that +column.
        9. +
      9. The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).
        10. +
      10. For consistency, the CLIENT PORT(S) column in the tcrules file +has been renamed SOURCE PORT(S).
        11. +
      11. The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now +shown in the output of "shorewall status".
        12. +
      12. A new IPTABLES option has been added to shorewall.conf. IPTABLES +can be used to designate the iptables executable to be used by +Shorewall. If not specified, the iptables executable determined by the +PATH setting is used.
        13. +
      13. You can now use the "shorewall show zones" command to display the +current contents of the zones. This is particularly useful if you use +dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
        +
        +    Example:
        +
        +      ursa:/etc/shorewall +# shorewall show zones
        +     +Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004
        +  
        +     loc
        +     +   eth0:192.168.1.0/24
        +     +   eth1:1.2.3.4
        +     +net      
        +     +   eth0:0.0.0.0/0
        +     WiFi
        +     +   eth1:0.0.0.0/0
        +     sec
        +     +   eth1:0.0.0.0/0
        +  
        +     +ursa:/etc/shorewall #
        +
        +
        14. +
      14. Variable expansion may now be used with the INCLUDE directive.
        +
        +    Example:
        +
        +    /etc/shorewall/params
        +
        +        FILE=/etc/foo/bar
        +
        +        Any other config file:
        +
        +        INCLUDE $FILE
        +
        +
        15. +
      15. The output of "shorewall status" now includes the results of "ip +-stat link ls". This helps diagnose performance problems caused by link +errors.
      16. Previously, when rate-limiting was specified in /etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded the specified rate was silently dropped. Now, if a log level is given in the entry (LEVEL column) then drops are logged at that level at a -rate of 5/min with a burst of 5.
        -
        17. -
      -Problems Corrected:
      -
        -
      1. A typo in the /etc/shorewall/interfaces file has been fixed.
        2. -
      2. "bad variable" error messages occurring during "shorewall stop" -and "shorewall clear" have been eliminated.
        3. -
      3. A misleading typo in /etc/shorewall/tunnels has been corrected. -The TYPE column for an IPIP tunnel should contain "ipip" rather than -"ip".
        -
        4. -
      -12/31/2004 -- Mandrake-specific RPMs available
      -
      -      Jack Coates has generously volunteered to provide Shorewall RPMs -for use under Mandrake. You can download Jack's RPMs from http://www.monkeynoodle.org/tmp/
      -
      -12/31/2004 -- Redhat/Fedora-specific RPMs available
      -
      -Simon Matter has graciously volunteered to provide RPMs taylored for -Redhat and Fedora. You can download Simon's RPMs from http://www.invoca.ch/pub/packages/shorewall/
      -
      -Thanks, Simon!
      -
      -12/30/2004 - -Shorewall 2.2.0 RC3
      -
      -Problems Corrected:
      -
        -
      1. The following error message could appear during "shorewall stop" -or "shorewall clear":
        -                                                                                                                                                                                                                 +rate of 5/min with a burst of 5.
        2. +
      2. Recent 2.6 kernels include code that evaluates TCP packets based +on TCP Window analysis. This can cause packets that were previously +classified as NEW or ESTABLISHED to be classified as INVALID.

        -              -local: lo:: bad variable name
        +The new kernel code can be disabled by including this command in your +/etc/shorewall/init file:
        +
        +    echo 1 > +/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
        +
        +Additional kernel logging about INVALID TCP packets may be obtained by +adding this command to /etc/shorewall/init:
        +
        +    echo 1 > +/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
        +
        +Traditionally, Shorewall has dropped INVALID TCP packets early. The new +DROPINVALID option allows INVALID packets to be passed through the +normal rules chains by setting DROPINVALID=No.
        +
        +If not specified or if specified as empty (e.g., DROPINVALID="") then +DROPINVALID=Yes is assumed.

        3. -
      3. The rate limiting example in /etc/shorewall/rules has been -changed to use the RATE LIMIT column.
        4. -
      4. Entries in /etc/shorewall/masq with the INTERFACE column -containing <ifname>:: (e.g., "eth0::") would generate a progress -message but would not generate an iptables rule.
        5. -
      5. A misleading typo in /etc/shorewall/tunnels has been corrected.
        +
      6. The "shorewall add" and "shorewall delete" commands now accept a +list of hosts to add or delete.
        +
        +Examples:
        +
        +    shorewall add +eth1:1.2.3.4 eth1:2.3.4.5 z12
        +    shorewall delete +eth1:1.2.3.4 eth1:2.3.4.5 z12
        +
        +    The above commands may also be written:
        +
        +    shorewall add +eth1:1.2.3.4,2.3.4.5 z12
        +    shorewall delete +eth1:1.2.3.4,2.3.4.5 z12
        +  
        +
        7. +
      7. TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel +type. OpenVPN entries in /etc/shorewall/tunnels have this format:
        +
        +    openvpn[:{tcp|udp}][:<port>]    +<zone>        <gateway>
        +
        +Examples:
        +
        +      openvpn:tcp    +     net    +1.2.3.4    # TCP tunnel on port 1194
        +     +openvpn:3344        net    +1.2.3.4    # UDP on port 3344
        +     +openvpn:tcp:4455    net    +1.2.3.4    # TCP on port 4455
        +
        +
        8. +
      8. A new 'ipsecvpn' script is included in the tarball and in the +RPM. The RPM installs the file in the Documentation directory +(/usr/share/doc/packages/shorewall-2.2.0-0RC1).
        +
        +This script is intended for use on Roadwarrior laptops for establishing +an IPSEC SA to/from remote networks. The script has some limitations:
        9. +
      +
        +
          +
        • Only one instance of the script may be used at a time.
          • +
        • Only the first SPD accessed will be instantiated at the remote +gateway. So while the script creates SPDs to/from the remote gateway +and each network listed in the NETWORKS setting at the front of the +script, only one of these may be used at a time.
          • +
        +
      +
        +
      1. The output of "shorewall status" now lists the loaded netfilter +kernel modules.
        2. +
      2. The range of UDP ports opened by the AllowTrcrt action has been +increased to 33434:33524.
        3. +
      3. The IANA has recently registered port 1194 for use by OpenVPN. In +previous versions of Shorewall (and OpenVPN), the default port was 5000 +but has been changed to 1194 to conform to the new OpenVPN default.
      -

      More News

      Leaf

      @@ -297,6 +851,14 @@ message but would not generate an iptables rule.
      2. LEAF is an open source project which provides a Firewall/router on a floppy, CD or CF. Several LEAF distributions including Bering and Bering-uClibc use Shorewall as their Netfilter configuration tool.

      +
      +

      OpenWRT

      +(OpenWRT Logo)OpenWRT +is a project which provides open source firmware for Linksys WRT54G +wireless routers. Two different Shorewall packages are available for +OpenWRT.

      Donations