releasenotes.txt

sharewall is very good

    Beginning with Shorewall-perl 4.2, all non-firewall zones will be
    treated as 'complex'. This will have the effect of one additional
    filter chain per zone but in most cases, the average number of
    filter rules traversed by a connection request will be reduced.

20) The need for interface-specific chains (such as eth0_in, eth4_fwd,
    etc.) in the filter table has been drastically reduced. This has
    the effect of reducing the average number of rules that each packet
    must traverse.

21) The default value for LOG_MARTIANS is now 'Yes' ('On' in
    Shorewall-perl). Previously, the default value was 'No' ('Off' in
    Shorewall-perl). The shorewall.conf file has also been 
    updated to specify a value of 'Yes' (which is interpreted as 'On'
    by Shorewall-perl).

22) Shorewall-perl now generates an error when a MAC address appears in
    a traffic shaping rule in the OUTPUT or POSTROUTING chains.

23) Macros are now self-commenting under control of a new AUTO_COMMENT
    option in shorewall.conf. When this option is set, if there is not
    a current comment when a macro is invoked, the behavior under
    Shorewall-perl is as if the first line of the macro file was
    "COMMENT <macro name>".

    So, if you have this rule:

            SSH/ACCEPT  loc         fw

    then the generated netfilter rule will include "/* SSH */" when
    viewed with 'iptables -L' or 'shorewall show loc2fw' or 'shorewall
    dump'.

    The AUTO_COMMENT option has a default value of 'Yes' and is only
    available under Shorewall-perl. The option is ignored by
    Shorewall-shell.

24) The default value for the IMPLICIT_CONTINUE option has been changed
    to 'No'.

25) Shorewall-perl now supports an 'l2tp' tunnel type. It opens UDP
    port 1701 in both directions and assumes that the source port will
    also be 1701. Some implementations (particularly OS X) use a
    different source port. In that case, you should use
    'generic:udp:1701' rather than 'l2tp'.

26) The /etc/shorewall/tcdevices and /etc/shorewall/tcclasses files
    have undergone some changes, especially when the 'classify' option
    has been specified.

    Normally Shorewall assigns interface numbers sequentially to
    devices listed in /etc/shorewall/tcdevices. Beginning with
    Shorewall 4.1.6, you can explicitly specify inteface numbers by
    prefixing the interface name with the interface number and a colon:

    Example:

     #INTERFACE    IN-BANDWITH     OUT-BANDWIDTH        OPTIONS
     1:eth0        1300kbit        384kbit              classify
     2:eth1        5600kbit        1000kbit        

     In /etc/shorewall/tcclasses:

     a) You can specify the INTERFACE using either the interface name
        or interface number.

     b) classes associated with devices which have the 'classify'
        option _must_ specify a class number by following the interface
        name/number with a colon (":") and the class number. The same
        class number may be used for classes defined on different
        interfaces but a class number may not be the same as any
        interface number.

    A class number may be specified when 'classify' has not been
    specified for the associated device. When a class number has not
    been given, the default class number remains the mark value
    prefixed by "1".

27) Shorewall now supports Intermediate Functional Block (IFB) devices.
    These devices allow shaping of incoming traffic.

    The 'ifb' module is available in the kernels included with today's
    distributions. You must load the module manually:

    If your distribution has modprobe:

       modprobe ifb [ numifbs=<number> ]

    Otherwise:

       insmod <path to net driver modules>/ifb.ko [ numifbs=<number> ]

    By default, the module automatically creates two IFB devices (ifb0
    and ifb1). To create only one, specify 'numifbs=1'.

    Example:

        ursa:~ # modprobe ifb numifbs=1
        ursa:~ # ip link ls
        1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
                link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
                link/ether cc:2b:cb:24:1b:00 brd ff:ff:ff:ff:ff:ff
        3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
                link/ether 00:1a:73:db:8c:35 brd ff:ff:ff:ff:ff:ff
        4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop qlen 32
               link/ether 26:99:d8:7d:32:26 brd ff:ff:ff:ff:ff:ff
        ursa:~ # 

    After you have created the IFB(s), you must bring it(them) up:

            ip link set dev ifb0 up

    You can place all of this in /etc/shorewall/init as follows:

            modprobe ifb numifbs=1
        ip link set dev ifb0 up

    The /etc/shorewall/tcdevices file has been extended to include an
    additional REDIRECTED DEVICES column. To convert your configuration
    to use an IFB:

    a) Look at your current /etc/shorewall/tcdevices file. Suppose you
       have:

        #INTERFACE  IN-BANDWIDTH  OUT-BANDWIDTH  OPTIONS
        eth0        1300kbit      384kbit        -

        Change it as follows:

        #INTERFACE  IN-BANDWIDTH  OUT-BANDWIDTH  OPTIONS  REDIRECTED
        #                                                 DEVICES
        eth0        -             384kkbit       -
        ifb0        -             1300kbit       -        eth0

       Note that the old IN-BANDWIDTH for eth0 has become the
       OUT-BANDWIDTH for ifb0 and that neither device has an
       IN-BANDWIDTH in the new configuration.

       Finally note that eth0 has been specified as a REDIRECTED device
       for the IFB.

    b) There are no Netfilter hooks between the real device (eth0) and
       the IFB (ifb0). So tcrules cannot be used to specify shaping of
       traffic leaving the IFB. To allow that traffic to be classified,
       a new /etc/shorewall/tcfilters file has been added.

       /etc/shorewall/tcfilters can be used for classifying traffic on
       any interface. When using entries in that file, it is important
       to realize that those entries act on packets as they appear 'on
       the wire'. That means that on output, SNAT/MASQUERADE has been
       applied and on input (output to an IFB), DNAT has not yet been
       applied.

       Columns in the file are:

       INTERFACE:CLASS

                The interface name or number followed by a colon (":")
                and the class number.

       SOURCE
                Source IP address. May be a host or network address.
                Specify "-" if any SOURCE address should match.

       DEST
                Destination IP address. May be a host or network
                address. Specify "-" if any DEST address should match.

       PROTO
                Protocol Name/Number. Specify "-" if any PROTO should
                match.

       DEST PORT(S)
                A comma-separated list of destination ports. May only
                be given if the PROTO is tcp, udp, icmp or
                sctp. Port ranges may be used, except when the PROTO is
                icmp. Specify "-" if any PORT should match.

       SOURCE PORT(S)
                A comma-separated list of source port. May only be
                given if the PROTO is tcp, udp or sctp. Port ranges
                may be used unless the protocol is icmp. Specify "-" if
                any PORT should match.

    Entries in /etc/shorewall/tcfilters generate U32 tc filters which
    may be displayed using the "shorewall show filters" ("shorewall-lite
    show filters") command. Note: The 'show filters' command is an
    alias for the existing 'show classifiers' command.

    Note that /etc/shorewall/tcfilters provides a usable alternative to
    HIGH_ROUTE_MARKS=Yes. You can use marks to select between providers
    and use entries in /etc/shorewall/tcfilters (or CLASSIFY tcrules)
    for traffic shaping.

28) If an interface fails when using balanced multi-ISP routing, the
    default route is lost. If there are remaining working interfaces
    with dynamic gateway addresses, Shorewall will be unable to
    determine those gateways.

    Beginning with Shorewall (Shorewall-lite) 4.1.7, the 'init' script
    may participate in gateway detection by setting variables with
    pre-determined names as follows:

         <gw>_GATEWAY

    where <gw> is the interface name:

          - in upper case
          - with any characters not allowed in shell variable names
            replaced by '_'.

    Example (from OpenWRT): 

          Interface:           eth0.1
          Variable:            ETH0_1_GATEWAY
          /etc/shorewall/init: 

              ETH0_1_GATEWAY=$(uci get /var/state/network.wan0.gateway)

29) A new CONNBYTES column has been added to the tcrules file. The
    column defines a byte or packet range that the connection must fall
    within in order for the rule to match. The contents are:

             [!]<min>:[<max>[:{O|R|B}[:{B|P|A}]]]

    !     matches if the the packet/byte count is not within the range 
          defined by <min> and <max>.

    <min> is an integer which defines the beginning of the byte/packet
          range.

    <max> is an integer which defines the end of the byte/packet range. 
          If omitted, only the beginning of the range is checked.

    The first letter gives the direction which the range refers to:

    O    - The original direction of the connection.
    R    - The opposite direction from the original connection.
    B    - The total of both directions.

    If omitted, 'B' is assumed.

    The second letter determins what the range refers to.

    B    - Bytes
    P    - Packets
    A    - Average packet size.

    If omitted, 'B' is assumed.

    Examples:

        1000000:          - Connection has transferred a total of
                            at least 1,000,000 bytes.

        1000000::R        - Connection has transferred at least
                            1,000,000 bytes in the direction opposite
                            of the original direction (typical of a
                            large download).

        1000000::O:P      - Connection has sent at least 1,000,000
                            packets in the direction of the original
                            connection.

30) A new MANGLE_ENABLED option is added to shorewall.conf. The default
    setting is 'Yes' which causes Shorewall to assume responsibility for
    the Netfilter mangle table.

    When MANGLE_ENABLED is set to 'No', Shorewall assumes no
    responsibility for that table. In this setting:

    a) Shorewall doesn't alter the mangle table.
    b) You may not use Shorewall Traffic Shaping (TC_ENABLED must be
       set to 'No'.
    c) The tcrules file is ignored.
    d) The providers file must be empty.
    e) All entries in tcdevices must specify the 'classify' option and
       traffic classification may only occur using the tcfilters file.

    This allows for another application running on your firewall to
    take over the mangle table and use it for it's own purposes.

31) Shorewall-perl now supports an ORIGINAL DEST column in macro files.
    The column must be left empty if the macro is to be used in the
    body of an action.

    The new column is placed between the SOURCE PORT(S) and RATE LIMIT
    columns. So that Shorewall-perl can determine which column layout
    each macro has, a new FORMAT directive is added:

             FORMAT {1|2}

    The default is FORMAT 1 which is the old format. FORMAT 2 specifies
    that the macro is in the new format.

32) Shorewall-perl implements a new Rfc1918 macro that deals with
    RFC 1918 addresses. This macro should be used in place of 
    the 'norfc1918' interface option which is deprecated.

    The macro body is:

    #ACTION             SOURCE          DEST    PROTO   DEST    SOURCE  ORIGINAL        RATE    USER/
    #                                                   PORT(S) PORT(S) DEST            LIMIT   GROUP
    FORMAT 2
    PARAM               SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 \
                                        DEST    -       -       -       -               -       -
    PARAM               SOURCE          DEST    -       -       -       10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

    The 'norfc1918' option on the interface associated with zone 'z'
    and with RFC1018_STRICT=Yes is equivalent to:

        Rfc1918(DROP)      z    all

33) A better way to perform RFC 1918 filtration is to null-route the
    address ranges reserved by RFC 1918. You can do that by setting the
    new NULL_ROUTE_RFC1918 option to 'Yes' in shorewall.conf.

    It is highly recommended that you also set ROUTE_FILTER=Yes to get
    Martian messages. These will help diagnose problems where you need
    to be able to access hosts with RFC 1918 addresses that are outside
    of your local networks. Sometimes, these can be subtle such as the