shorewall_code/Shorewall-common/releasenotes.txt

Shorewall 4.1 Patch Release 6.

----------------------------------------------------------------------------
               R E L E A S E  4 . 1  H I G H L I G H T S
----------------------------------------------------------------------------
1) Support is included for multiple internet providers through the same
   ethernet interface.

2) Support for NFLOG has been added.

3) Enhanced operational logging.

4) The tarball installers now work under Cygwin.

5) Shorewall-perl now supports IFB devices which allow traffic shaping of
   incoming traffic.

6) Shorewall-perl supports definition of u32 traffic classification
   filters.

Migration Issues.

1)  Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
    mark values < 256 to be assigned in the OUTPUT chain. This has been
    changed so that only high mark values may be assigned
    there. Packet marking rules for traffic shaping of packets
    originating on the firewall must be coded in the POSTROUTING table.

2)  Previously, Shorewall did not range-check the value of the
    VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.1:

    a) A VERBOSITY setting outside the range -1 through 2 is rejected.
    b) After the -v and -q options are applied, the resulting value is
       adjusted to fall within the range -1 through 2.

3)  Specifying a destination zone in a NAT-only rule now generates a
    warning and the destination zone is ignored. NAT-only rules are:

    	     NONAT
	     REDIRECT-
	     DNAT-

4)  The default value for LOG_MARTIANS has been changed. Previously,
    the defaults were:

    	Shorewall-perl - 'Off'
	Shorewall-shell - 'No'

    The new default values are:

    	Shorewall-perl - 'On'
	Shorewall-shell - 'Yes'.

    Shorewall-perl users may:

    a) Accept the new default -- martians will be logged from all
       interfaces with route filtering except those with log_martians=0
       in /etc/shorewall/interfaces.

    b) Explicitly set LOG_MARTIANS=Off to maintain compatibility with
       prior versions of Shorewall.

    Shorewall-shell users may:

    a) Accept the new default -- martians will be logged from all
       interfaces with the route filtering enabled.

    b) Explicitly set LOG_MARTIONS=No to maintain compatibility with 
       prior versions of Shorewall.

5)  The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) has
    been changed from Yes to No.

Problems corrected in Shorewall-perl 4.1.6.

1)  A problem introduced in 4.1.5 would result in the following error
    message.

	ERROR: Internal error in create_netfilter_load()	

2)  Under Shorewall-perl, if an empty action was invoked or was named
    in one of the DEFAULT_xxx options in shorewall.conf, an
    iptables-restore error occured.

3)  If $ADMIN was empty, then the rule:

       ACCEPT loc:$ADMIN all

    became

       ACCEPT loc   net

    It is now flagged as an error.

Problems corrected in Shorewall-shell 4.1.6.

1)  Specifying a value for ACCEPT_DEFAULT or QUEUE_DEFAULT resulted in
    a fatal error at compile time. 

New Features in 4.1.6.

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

2)  A REDIRECTED INTERFACES option has been added to the tcdevices file
    to support using an IFB (Intermediate Functional Block) device.

    IFBs can be used to shape incoming traffic by redirecting that
    traffic through the IFB.

    To use this feature:

       a) Specify the name of your IFB in the INTERFACE column.
       b) List the redirected device names (comma-separated) in the
          REDIRECTED INTERFACES column.

    Packets that are input from the redirected interface(s) will appear
    as output packets on the IFB.

    This support should be considered EXPERIMENTAL.

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

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

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

    The module automatically creates two IFB devices by default (ifb0
    and ifb1). To create only one, specify 'numifbs'.

    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 using 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
	        Destination port. May only be given if the PROTO is
	        tcp, udp or sctp. Neither port ranges nor port lists
	        may be given. Specify "-" if any PORT should match.

       SOURCE PORT
	        Source port. May only be given if the PROTO is
	        tcp, udp or sctp. Neither port ranges nor port lists
	        may be given. Specify "-" if any PORT should match.

    Entries in /etc/shorewall/tcfilters generate U32 tc filters which
    may be displayed using the "shorewall show tc" ("shorewall-lite
    show tc") 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.

New Features in Shorewall 4.1.

1)  Shorewall 4.1 contains support for multiple Internet providers
    through a single ethernet interface. Configuring two providers
    through a single interface differs from two providers through two
    interfaces in several ways.

    a) Only ethernet (or ethernet-like) interfaces can be used. For
       inbound traffic, the MAC addresses of the gateway routers is used
       to determine which provider a packet was received through. Note
       that only routed traffic can be categorized using this technique.

    b) You must specify the address on the interface that corresponds to
       a particular provider in the INTERFACE column by following the
       interface name with a colon (":") and the address.
 
    c) Entries in /etc/shorewall/masq must be qualified by the provider
       name (or number).

    d) This feature requires Realm Match support in your kernel and
       iptables. If you use a capabilities file, you need to regenerate
       the file with Shorewall 4.1 or Shorewall-lite 4.1.
 
    e) You must add route_rules entries for networks that are accessed
       through a particular provider.

    f) If you have additional IP addresses through either provider,
       you must add route_rules to direct traffic FROM each of those
       addresses through the appropriate provider.

    g) You must add MARK rules for any traffic that you know originates
       from a particular provider.

     Example:

     Providers Blarg (1) and Avvanta (2) are both connected to
     eth0. The firewall's IP address with Blarg is 206.124.146.176/24
     (gateway 206.124.146.254) and the IP address from Avvanta is
     130.252.144.8/24 (gateway 130.252.144.254). We have a second IP
     address (206.124.146.177) from Blarg.

     /etc/shorewall/providers:

       #PROVIDER   NUMBER  MARK    DUPLICATE INTERFACE            GATEWAY
       Blarg       1       1       main      eth0:206.124.146.176 206.124.146.254 ...
       Avvanta     2       2       main      eth0:130.252.144.8   130.252.144.254 ...

     /etc/shorewall/masq:

       #INTERFACE          SOURCE          ADDRESS
       eth0(Blarg)         130.252.144.8   206.124.146.176
       eth0(Avvanta)       206.124.146.176 130.252.144.8
       eth0(Blarg)         eth1            206.124.146.176
       eth0(Avvanta)       eth1            130.252.144.8

     /etc/shorewall/route_rules:

	#SOURCE		DEST			PROVIDER	PRIORITY
	-		206.124.146.0/24	Blarg		1000
	-		130.252.144.0/24	Avvanta		1000
	206.124.146.177	-			Blarg		26000

     /etc/shorewall/tcrules

	#MARK/CLASSIFY  SOURCE	               DEST
	1		eth0:206.124.146.0/24  0.0.0.0/0
	2		eth0:130.242.144.0/24  0.0.0.0/0

2)  You may now include the name of a table (nat, mangle or filter) in
    a 'shorewall refresh' command by following the table name with a
    colon (e.g., mangle:). This causes all non-builtin chains in the
    table to be reloaded.

    Example:

	shorewall refresh nat:

3)  When no chain name is given to the 'shorewall refresh' command, the
    mangle table is refreshed along with the blacklist chain (if
    any). This allows you to modify /etc/shorewall/tcrules and install
    the changes using 'shorewall refresh'.

4)  Support for the NFLOG log target has been added. NFLOG is a
    successor to ULOG. In addition, both ULOG and NFLOG may be followed
    by a list of up to three numbers in parentheses.

    The first number specifies the netlink group (1-32). If omitted
    (e.g., NFLOG(,0,10)) then a value of 1 is assumed.

    The second number specifies the maximum number of bytes to copy. If
    omitted, 0 (no limit) is assumed.

    The third number specifies the number of log messages that should
    be buffered in the kernel before they are sent to user space. The
    default is 1.

    Examples:

    /etc/shorewall/shorewall.conf:

	MACLIST_LOG_LEVEL=NFLOG(1,0,1)

    /etc/shorewall/rules:

	ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080

5)  Shorewall-perl 4.1 implements an alternative syntax for macro
    parameters and for the NFQUEUE queue number. Rather than following
    the macro name (or NFQUEUE) with a slash ("/") and the parameter,
    the parameter may be enclosed in parentheses.

    Examples -- each pair shown below are equivalent:

    DNS/ACCEPT	     DNS(ACCEPT)
    NFQUEUE/3	     NFQUEUE(3)
    
    The old syntax will still be accepted but will cease to be documented
    in some future Shorewall release.

6)  Shorewall 4.1 contains enhanced operational logging capabilities
    through a set of related enhancements to Shorewall-common and
    Shorewall-perl. The enhancements are not supported by
    Shorewall-shell nor are they supported by Shorewall-lite except
    when the script is compiled using Shorewall-perl.

    a)  The STARTUP_LOG option in /etc/shorewall/shorewall.conf gives
        the name of the Shorewall operational log. The log will be
        created if it does not exist.

    b)  The LOG_VERBOSITY option in /etc/shorewall/shorewall.conf gives
        the verbosity at which logging will occur. It uses the same
        value range as VERBOSITY:

	-1    Do not log
	0     Almost quiet
	1     Only major steps
	2     Verbose

    c)  An absolute VERBOSITY may be specified on the command line
        using the -v option followed by -1,0,1 or 2.

	Example:

		shorewall -v2 check

    d)  The /etc/init.d/shorewall script supplied with the
        shorewall.net packages sets '-v0' as the default. This may be
        overridden with the OPTIONS setting in /etc/defaults/shorewall or
        /etc/sysconfig/shorewall.

    Logging occurs on both Shorewall-perl and the generated script when
    the following commands are issued:

	start
	restart
	refresh

    Messages in the log are always timestamped.

    This change implemented two new options to the Shorewall-perl
    compiler (/usr/share/shorewall-perl/compiler.pl).

	     --log=<logfile>
	     --log_verbosity={-1|0-2}

    The --log option is ignored when --log_verbosity is not supplied or
    is supplied with value -1.

    To avoid a proliferation of parameters to
    Shorewall::Compiler::compile(), that function has been changed to
    use named parameters. Parameter names are:

	 object          Object file. If omitted or '', the
			 configuration is syntax checked. 
	 directory       Directory. If omitted or '', configuration
			 files are located using
			 CONFIG_PATH. Otherwise, the directory named by
			 this parameter is searched first.
	 verbosity       Verbosity; range -1 to 2
	 timestamp       0|1 -- timestamp messages.
	 debug           0|1 -- include stack trace in warning/error
			 messages. 
	 export          0|1 -- compile for export.
	 chains          List of chains to be reloaded by 'refresh'.
	 log             File to log compiler messages to.
	 log_verbosity   Log Verbosity; range -1 to 2.

    Those parameters that are supplied must have defined values.

    Defaults are:

	     object		'' ('check' command)
	     directory		''
	     verbosity		1
	     timestamp		0
	     debug		0
	     export		0
	     chains		''
	     log		''
	     log_verbosity	-1
	     

    Example:

    use lib '/usr/share/shorewall-perl/';
    use Shorewall::Compiler;

    compiler( object        => '/root/firewall', 
              log           => '/root/compile.log',
	      log_verbosity => 2 );

7)  Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
    mark values < 256 to be assigned in the OUTPUT chain. This has been
    changed so that only high mark values may be assigned
    there. Packet marking rules for traffic shaping of packets
    originating on the firewall must be coded in the POSTROUTING chain.

8)  Previously, Shorewall did not range-check the value of the
    VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.1:

    a) A VERBOSITY setting outside the range -1 through 2 is rejected.
    b) After the -v and -q options are applied, the resulting value is
       adjusted to fall within the range -1 through 2.

9)  The tcdevices file has been extended to include an OPTIONS
    column. Currently only a single option is defined.

    classify   When specified, you must use explicit CLASSIFY tcrules
	       to classify traffic by class. Shorewall will not create
               any CLASSIFY rules to classify traffic by mark value.

    The 'classify' option should be specified when you want to do all
    classification using CLASSIFY tcrules. Because CLASSIFY is not a
    terminating target, every packet passes through all CLASSIFY
    rules. 'classify' can prevent packets from having to pass through
    useless additional rules.

    Example:

    /etc/shorewall/tcdevices

	#INTERFACE	IN-BANDWITH	OUT-BANDWIDTH	OPTIONS
	$EXT_IF		1300kbit	384kbit		classify

    /etc/shorewall/tcclasses

	#INTERFACE MARK	RATE	  CEIL	    PRIORITY OPTIONS
	$EXT_IF	   10	5*full/10 full	    1	     tcp-ack,tos-minimize-delay
	$EXT_IF	   20	2*full/10 6*full/10 2	     default
	$EXT_IF	   30	2*full/10 6*full/10 3

    /etc/shorewall/tcrules

	#MARK	SOURCE		DEST	PROTO	PORT(S)	SOURCE
	#                                               PORT(S)
	1:110	192.168.0.0/22	$EXT_IF         
	1:130	206.124.146.177 $EXT_IF	tcp     -       873

    This example shows my own simple traffic shaping configuration. I
    have three classes; one for traffic from our local network, one for
    rsync from the master shorewall.net server, and one for all other
    DMZ traffic. I use CLASSIFY rules to assign traffic to the first
    and third class and let the rest default to the second class.

10) COMMENT lines are now supported in macro bodies by Shorewall-perl
    and are ignored by the Shorewall-shell compiler.

    COMMENT lines in macros work slightly differently from COMMENT
    lines in other files. COMMENT lines in macros are ignored if
    COMMENT support is not available or if there was a COMMENT in use
    when the top-level macro was invoked. This allows the
    following:

	/etc/shorewall/macro.SSH:

	    #ACTION SOURCE  PROTO   DEST    SOURCE  RATE    USER/
	    #                       PORT(S) PORT(S) LIMIT   GROUP
	    COMMENT My SSH Macro
	    PARAM   -       -       tcp     22

	/etc/shorewall/rules:

	    COMMENT Allow SSH from home
	    SSH/ALLOW     net:$MYIP	$FW
	    COMMENT
   
	The comment line in macro.SSH will not override the 
	COMMENT line in the rules file and the generated rule will show

		/* Allow SSH from home */

	when displayed through the Shorewall show and dump commands.

    If a macro is invoked and there is no current comment, then the
    name of the macro automatically becomes the current comment. This
    makes macros self-commenting.   

11) If the program named in SHOREWALL_SHELL doesn't exist or is not
    executable, Shorewall and Shorewall-lite now both fall back to
    /bin/sh after issuing a warning message. Previously, both
    terminated with a fatal error.

12) Shorewall-perl now generates fatal error conditions if there are
    no IPv4 zones defined or there are no interfaces defined.

13) Shorewall now unconditionally uses tc filter rules to classify
    traffic by MARK value. Previously, Shorewall used the CLASSIFY
    target in the POSTROUTING chain if it was available.

14) The Shorewall-common installer (install.sh) now works on Windows
    under Cygwin.

    To install Shorewall-perl under Cygwin:

    $ tar -zxf shorewall-perl-4.x.y.tar.bz2
    $ tar -zxf shorewall-common-4.x.y.tar.bz2
    $ cd shorewall-perl-4.x.y
    $ USER=<your user id> GROUP=None ./install.sh
    $ cd ../shorewall-common-4.x.y
    $ USER=<your user id> GROUP=None ./install.sh
    
    The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).

15) When installing on Cygwin, /etc/shorewall is no longer fully
    populated. Rather, only the shorewall.conf and params files are
    installed. As always, the full configuration file set is installed
    in /usr/share/shorewall/configfiles.

16) Specifying a destination zone in a NAT-only rule now generates a
    warning and the destination zone is ignored. NAT-only rules are:

    	     NONAT
	     REDIRECT-
	     DNAT-

17)  The /etc/shorewall/masq and /etc/shorewall/nat file now accept a
    comma-separated list of interface names where before only a single
    interface name could be listed (Shorewall-perl only).

    This feature is not for beginners. It iterates over the
    list of interfaces, substituting each interface in place of the
    list and processing the resulting entry according to the semantics
    of earlier Shorewall versions. If you don't know where to use this,
    don't try.

    Example 1:

    /etc/shorewall/masq:

    #INTERFACE              SOURCE          ADDRESS
    eth0,eth1		    eth2	    1.2.3.4

    equivalent to:

    #INTERFACE              SOURCE          ADDRESS
    eth0		    eth2	    1.2.3.4
    eth1		    eth2	    1.2.3.4

    Example 2:

    /etc/shorewall/masq:

    #INTERFACE			SOURCE      ADDRESS
    eth0,eth1::192.168.1.0/24	eth2	    1.2.3.4

    equivalent to:

    #INTERFACE              SOURCE          ADDRESS
    eth0::192.168.1.0/24    eth2	    1.2.3.4
    eth1::192.168.1.0/24    eth2	    1.2.3.4

    Example 3:

    /etc/shorewall/nat:

    #EXTERNAL        INTERFACE       INTERNAL
    206.124.146.178  eth0,wlan0      192.168.1.3

    equivalent to:

    #EXTERNAL        INTERFACE       INTERNAL
    206.124.146.178  eth0            192.168.1.3
    206.124.146.178  wlan0           192.168.1.3

18) Previously, the INTERFACE name used in the masq, nat and netmap
    files had to exactly match the name of an interface from the
    interfaces file. Beginning with Shorewall-perl 4.1.4, the
    interface may loosely match a wildcard entry in the interfaces
    file.

    Example:

    /etc/shorewall/interfaces:

	vpn	tun+	

    /etc/shorewall/masq:

	tun1	192.168.4.0/24

19) Previously, Shorewall classified non-firewall zones as either
    'simple' or 'complex'. Attributes of a zone which made it 'complex'
    included:

    - The zone was of type 'ipsec' or 'ipsec4' or it had a hosts
      entry with the 'ipsec' options.
    - The zone had OPTIONS, IN OPTIONS or OUT OPTIONS
    - The zone had more than one network on a given interface
    - The zone had a hosts file entry with an exclusion.
    - The zone had a hosts file entry specifying an ipset.

    The handling of 'simple' and 'complex' zones was different.

    -  complex zones had their own 'forward' chain (named
       '<zone>_frwd').
    -  complex zones with exclusions had their own 'input' and
       'output' chains.

    Beginning with Shorewall-perl 4.1, 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.