diff --git a/docs/Actions.xml b/docs/Actions.xml index 292d51d6a..a67be7f3b 100644 --- a/docs/Actions.xml +++ b/docs/Actions.xml @@ -41,9 +41,10 @@ - This article applies to Shorewall 4.0 and later. If you are running - a version of Shorewall earlier than Shorewall 4.0.0 then please see the - documentation for that release. + This article applies to Shorewall 4.3 and + later. If you are running a version of Shorewall earlier than Shorewall + 4.3.5 then please see the documentation for that + release.
@@ -104,9 +105,8 @@ ACCEPT - - tcp 135,139,445 file to /etc/shorewall (or somewhere else on your CONFIG_PATH) and modify the copy. - Standard Actions were largely replaced by macros in Shorewall 3.0 and later major - versions. + Standard Actions have been largely replaced by macros . @@ -121,19 +121,6 @@ ACCEPT - - tcp 135,139,445
-
- Enabling the Use of Actions - - In Shorewall version 3.4 and later, to make use of any of the three - types of actions you must set the USE_ACTIONS option to Yes in - /etc/shorewall/shorewall.conf. - - - Shorewall-perl will complain if USE_ACTIONS=No since that compiler - always includes the capability to use actions. - -
-
Default Actions (Formerly Common Actions) @@ -185,10 +172,9 @@ ACCEPT - - tcp 135,139,445
Limiting Per-IP Connection Rate - Beginning with Shorewall 3.0.4, Shorewall has a Limit - action. Limit is invoked with a - comma-separated list in place of a logging tag. The list has three - elements: + Shorewall supports a Limit action. Limit is invoked with a comma-separated + list in place of a logging tag. The list has three elements: @@ -251,45 +237,8 @@ Limit:info:SSHA,3,60 net $FW tcp 22 How Limit is Implemented - For those who are curious, the Limit action is implemented in - Shorewall 3.0 and Shorewall 3.2 as follows: - - - - The file /usr/share/shorewall/action. - Limit is empty. - - - - The file /usr/share/shorewall/Limit is as - follows: - - set -- $(separate_list $TAG) - -[ $# -eq 3 ] || fatal_error "Rule must include <set name>,<max connections>,<interval> as the log tag" - -run_iptables -A $CHAIN -m recent --name $1 --set - -if [ -n "$LEVEL" ]; then - run_iptables -N $CHAIN% - log_rule_limit $LEVEL $CHAIN% $1 DROP "" "" -A - run_iptables -A $CHAIN% -j DROP - run_iptables -A $CHAIN -m recent --name $1 --update --seconds $3 --hitcount $(( $2 + 1 )) -j $CHAIN% -else - run_iptables -A $CHAIN -m recent --update --name $1 --seconds $3 --hitcount $(( $2 + 1 )) -j DROP -fi - -run_iptables -A $CHAIN -j ACCEPT - - - - In Shorewall 3.3, Limit is made into a built-in action; basically - that means that the above code now lives inside of Shorewall rather than - in a separate file. - - For completeness, here's the above - /usr/share/shorewall/Limit for use with - Shorewall-perl: + For those who are curious, the Limit action is implemented as + follows: my @tag = split /,/, $tag; @@ -537,7 +486,7 @@ add_rule $chainref, '-j ACCEPT'; - MARK (Added in Shorewall 3.4.4) + MARK [!]<value>[/<mask>][:C] @@ -743,20 +692,12 @@ acton:info:test $FW net /etc/shorewall/actionsDropBcasts - /etc/shorewall/action.DropBcasts# This file is emptyWhen - using Shorewall-shell: - -
- /etc/shorewall/DropBcasts[ -n "$LEVEL" ] && log_rule_limit $LEVEL $CHAIN DropBcasts DROP "" "$TAG" -A -run_iptables -A DropBcasts -m pkttype --pkttype broadcast -j DROP -
When using Shorewall-Perl:
- /etc/shorewall/DropBcastsuse Shorewall::Chains; + /etc/shorewall/action.DropBcasts# This file is empty/etc/shorewall/DropBcastsuse Shorewall::Chains; log_rule_limit( $level, $chainref, 'DropBcasts', 'DROP', '', $tag, 'add', '' ) if $level ne ''; add_rule( $chainref, '-m pkttype --pkttype broadcast -j DROP' ); 1; -
For a richer example, see this diff --git a/docs/Anatomy.xml b/docs/Anatomy.xml index 44dcb8131..5a18c6f21 100644 --- a/docs/Anatomy.xml +++ b/docs/Anatomy.xml @@ -5,7 +5,7 @@ - Anatomy of Shorewall 4.0 + Anatomy of Shorewall 4.3 @@ -20,6 +20,8 @@ 2007 + 2009 + Thomas M. Eastep @@ -37,47 +39,46 @@
Products - Shorewall 4.0 consists of four packages. + Shorewall 4.3 consists of four packages. - Shorewall-common. This package - must be installed on at least one system in your network. That system - must also have Shorewall-shell and/or Shorewall-perl installed. + Shorewall. This package must be + installed on at least one system in your network. It contains + everything needed to create an IPv4 firewall. - Shorewall-shell. This package - includes the legacy Shorewall configuration compiler written in Bourne - Shell. This compiler is very portable but suffers from performance - problems and has become hard to maintain. - - - - Shorewall-perl. An alternative - to Shorewall-shell written in the Perl language. This compiler is - highly portable to those Unix-like platforms that support Perl - (including Cygwin) and is the compiler of choice for new Shorewall - installations. + Shorewall6. This package + requires the Shorewall package and adds those components needed to + create an IPv6 fireawall. Shorewall-lite. Shorewall - allows for central administration of multiple firewalls through use of - Shorewall lite. The full Shorewall product (including Shorewall-common - with Shorewall-shell and/or Shorewall-perl) is installed on a central - administrative system where compiled Shorewall scripts are generated. - These scripts are copied to the firewall systems where they run under - the control of Shorewall-lite. + allows for central administration of multiple IPv4 firewalls through + use of Shorewall lite. The full Shorewall product is installed on a + central administrative system where compiled Shorewall scripts are + generated. These scripts are copied to the firewall systems where they + run under the control of Shorewall-lite. + + + + Shorewall6-lite. Shorewall + allows for central administration of multiple IPv4 firewalls through + use of Shorewall lite. The full Shorewall product is installed on a + central administrative system where compiled Shorewall scripts are + generated. These scripts are copied to the firewall systems where they + run under the control of Shorewall-lite.
- Shorewall-common + Shorewall - The Shorewall-common package includes a large number of files which - are installed in /sbin, The Shorewall package includes a large number of files which are + installed in /sbin, /usr/share/shorewall, /etc/shorewall, /etc/init.d and + + compiler.pl - The configuration compiler + perl program. + + configfiles - A directory containing configuration files to copy to create a /etc/shorewall/modules. + + prog.* - Shell program fragments used as + input to the compiler. + + + + Shorewall - Directory + containing the Shorewall Perl modules used by the compiler. + + version - A file containing the currently install version of Shorewall. @@ -178,7 +194,7 @@
/etc/shorewall - This is where the modifiable configuration files are + This is where the modifiable IPv4 configuration files are installed.
@@ -199,14 +215,6 @@ url="manpages/shorewall-vardir.html">shorewall-vardir(5). - - chains - If DYNAMIC_ZONES=Yes in shorewall.conf(5), this - file contains information used by the add and - delete commands (see shorewall(8)). - - .iptables-restore-input - The file passed as input to the iptables-restore program to initialize the firewall @@ -290,69 +298,175 @@
-
- Shorewall-shell - - The Shorewall-shell product installs all of its files in - /usr/share/shorewall-shell. - - - - compiler - The configuration compiler shell - program. - - - - lib.* - Shell function libraries used by - the compiler. On embedded systems, only a sub-set of the available - libraries may be installed as a space-saving measure. - - - - prog.* - Shell program fragments used as - input to the compiler. - - - - version - A file containing the currently - install version of Shorewall-shell. - - -
-
- Shorewall-perl + Shorewall6 - The Shorewall-perl product installs all of its files in - /usr/share/shorewall-perl. + Shorewall6 installs its files in a number of directories: - - - buildports.pl - A Perl program that builds - the Shorewall/Ports.pm module during installation (This program is - removed in Shorewall 4.0.5 and later releases) - +
+ /sbin - - compiler.pl - The configuration compiler - perl program. - + The /sbin/shorewall6 shell program is used to + interact with Shorewall6. See shorewall6(8). +
- - prog.* - Shell program fragments used as - input to the compiler. - +
+ /usr/share/shorewall6 - - Shorewall - Directory - containing the Shorewall Perl modules used by the compiler. - + The bulk of Shorewall6 is installed here. - - version - A file containing the currently - install version of Shorewall-shell. - - + + + action.template - template file for + creating actions. + + + + action.* - standard Shorewall + actions. + + + + actions.std - file listing the standard + actions. + + + + configfiles - A + directory containing configuration files to copy to create a Shorewall6-lite export + directory. + + + + configpath - A file + containing distribution-specific path assignments. + + + + firewall - A shell program that handles + the add and delete commands + (see shorewall(8)). It + also handles the stop and + clear commands when there is no current compiled + firewall script on the system. + + + + functions - A symbolic + link to lib.base that provides for + compatibility with older versions of Shorewall. + + + + lib.* - Shell function libraries used by + the other shell programs. + + + + modules - File that drives the loading of + Netfilter kernel modules. May be overridden by + /etc/shorewall/modules. + + + + version - A file containing the currently + install version of Shorewall. + + + + wait4ifup - A shell program that extension scripts can + use to delay until a network interface is available. + + +
+ +
+ /etc/shorewall6 + + This is where the modifiable IPv6 configuration files are + installed. +
+ +
+ /var/lib/shorewall6 + + Shorewall6 doesn't install any files in this directory but rather + uses the directory for storing state information. This directory may be + relocated using shorewall-vardir(5). + + + + .ip6tables-restore-input - The file + passed as input to the ip6tables-restore program to initialize the + firewall during the last start or + restart command (see shorewall6(8)). + + + + .modules - The contents of the modules + file used during the last start or + restart command (see shorewall(8) for command + information). + + + + .modulesdir - The MODULESDIR setting + (shorewall.conf(5)) at the + last start or restart. + + + + .refresh - The shell program that + performed the last successful refresh + command. + + + + .restart - The shell program that + performed the last successful restart + command. + + + + restore - The default shell program used + to execute restore commands. + + + + .restore - The shell program that + performed the last successful refresh, restart or + start command. + + + + save - File created by the + save command and used to restore the dynamic + blacklist during start/restart. + + + + .start - The shell program that performed + the last successful start command. + + + + state - Records the current firewall + state. + + + + zones - Records the current zone + contents. + + +
@@ -363,8 +477,8 @@ class="directory">/usr/share/shorewall-lite, /etc/shorewall-lite, /etc/init.d and /var/lib/shorewall/. These are described in - the sub-sections that follow. + class="directory">/var/lib/shorewall-lite/. These are described + in the sub-sections that follow.
/sbin @@ -544,4 +658,181 @@
+ +
+ Shorewall6-lite + + The Shorewall6-lite product includes files installed in /sbin, /usr/share/shorewall6-lite, /etc/shorewall6-lite, + /etc/init.d and /var/lib/shorewall6-lite/. These are + described in the sub-sections that follow. + +
+ /sbin + + The /sbin/shorewall6-lite shell program is + use to interact with Shorewall lite. See shorewall6-lite(8). +
+ +
+ /etc/init.d or /etc/rc.d (depends on distribution) + + An init script is installed here. Depending on the distribution, + it is named shorewall6-lite or + rc.firewall. +
+ +
+ /etc/shorewall6-lite + + This is where the modifiable configuration files are + installed. +
+ +
+ /usr/share/shorewall6-lite + + The bulk of Shorewall-lite is installed here. + + + + configpath - A file + containing distribution-specific path assignments. + + + + functions - A symbolic + link to lib.base that provides for + compatibility with older versions of Shorewall. + + + + lib.* - Shell function libraries used by + the other shell programs. These are copies of the corresponding + libraries in the Shorewall product. + + + + modules - File that drives the loading of + Netfilter kernel modules. May be overridden by + /etc/shorewall-lite/modules. + + + + shorecap - A shell program used for + generating capabilities files. See the Shorewall-lite + documentation. + + + + version - A file containing the currently + install version of Shorewall. + + + + wait4ifup - A shell program that extension scripts can + use to delay until a network interface is available. + + +
+ +
+ /var/lib/shorewall6-lite + + Shorewall6-lite doesn't install any files in this directory but + rather uses the directory for storing state information. This directory + may be relocated using shorewall-lite-vardir(5). + + + + firewall - Compiled shell script + installed by running the load or reload command on the + administrative system (see shorewall6(8)). + + + + firewall.conf - Digest of the + shorewall.conf file used to compile the firewall script on the + administrative system. + + + + + + .ip6tables-restore-input - The file + passed as input to the ip6tables-restore program to initialize the + firewall during the last start or + restart command (see shorewall-lite(8)). + + + + .modules - The contents of the modules + file used during the last start or + restart command (see shorewall-lite(8) for + command information). + + + + .modulesdir - The MODULESDIR setting + (shorewall.conf(5)) at the + last start or restart. + + + + .refresh - The shell program that + performed the last successful refresh + command. + + + + .restart - The shell program that + performed the last successful restart + command. + + + + restore - The default shell program used + to execute restore commands. + + + + .restore - The shell program that + performed the last successful refresh, restart or + start command. + + + + save - File created by the + save command and used to restore the dynamic + blacklist during start/restart. + + + + .start - The shell program that performed + the last successful start command. + + + + state - Records the current firewall + state. + + + + zones - Records the current zone + contents. + + +
+
diff --git a/docs/CompiledPrograms.xml b/docs/CompiledPrograms.xml index 098e8121d..c11c5f798 100644 --- a/docs/CompiledPrograms.xml +++ b/docs/CompiledPrograms.xml @@ -35,20 +35,20 @@ - This article applies to Shorewall 4.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 4.0.0 then please see the documentation appropriate for your + 4.3.5 then please see the documentation appropriate for your version.
Overview - Beginning with Shorewall version 3.1, Shorewall has the capability - to compile a Shorewall configuration and produce a runnable firewall - program script. The script is a complete program which can be placed on a - system with Shorewall Lite installed and can serve as - the firewall creation script for that system. + Shorewall has the capability to compile a Shorewall configuration + and produce a runnable firewall program script. The script is a complete + program which can be placed on a system with Shorewall + Lite installed and can serve as the firewall creation script + for that system.
Restrictions @@ -63,16 +63,11 @@ option is not supported. - - DYNAMIC_ZONES=Yes in shorewall.conf is - not supported. - - All extension scripts used are copied into the program (with the exception of those - executed at compile-time by Shorewall-perl). The - ramifications of this are: + executed at compile-time by the compiler). The ramifications + of this are: @@ -81,9 +76,8 @@ - Beginning with Shorewall 3.2.9 and 3.4.0 RC2, the - params file is only processed at compile - time if you set EXPORTPARAMS=No in + The params file is only processed at + compile time if you set EXPORTPARAMS=No in shorewall.conf. For run-time setting of shell variables, use the init extension script. Although the default setting is EXPORTPARAMS=Yes for @@ -121,8 +115,8 @@ command:
- shorewall compile [ -e ] [ C {perl|shell} ] [ - <directory name> ] <path name> + shorewall compile [ -e ] [ <directory name> ] + <path name>
where @@ -147,16 +141,6 @@ - - -C {perl|shell} - - - Specifies the compiler to use. Overrides the - SHOREWALL_COMPILER setting in shorewall.conf. - - - <directory name> @@ -223,19 +207,10 @@ The /etc/shorewall/shorewall.conf file is - used to determine several settings during the compilation process, - even though there is a shorewall.conf file in the export directory. - /sbin/shorewall uses the SHOREWALL_COMPILER - setting from /etc/shorewall/shorewall.conf to - determine which compiler to launch. If the compiler is - shorewall-shell, then the SHOREWALL_SHELL setting from - /etc/shorewall/shorewall.conf determines the - shell to use. /sbin/shorewall also uses the - VERBOSITY setting from - /etc/shorewall/shorewall.conf for determining how - much output the compiler generates. All other settings are taken from - the shorewall.conf file in the remote systems - export directory. + used to determine the VERBOSITY setting which determines how much + output the compiler generates. All other settings are taken from the + shorewall.conf file in the remote systems export + directory. If you want to be able to allow non-root users to manage @@ -321,7 +296,7 @@ /sbin/shorewall load -c gateway Although scp and ssh are used by default, you can use other utilities by setting RSH_COMMAND and RCP_COMMAND in - /etc/shorewall/shorewall.conf. + /etc/shorewall/shorewall.conf. @@ -339,9 +314,9 @@ command compiles a firewall script from the configuration files in the current working directory (using shorewall compile -e), copies that file to the remote system via scp and - restarts Shorewall Lite on the remote system via ssh. Note: In - Shorewall 3.2.6 and later, the reload - command also supports the '-c' option. + restarts Shorewall Lite on the remote system via ssh. The reload command also supports the '-c' + option. I personally place a Makefile in each export directory as follows: @@ -594,11 +569,11 @@ clean: If you set variables in the params file, there are a couple of issues: - Beginning with Shorewall 3.2.9 and 3.4.0 RC2, the - params file is only processed at compile time - if you set EXPORTPARAMS=No in shorewall.conf. - For run-time setting of shell variables, use the - init extension script. + The params file is not processed at run + time if you set EXPORTPARAMS=No in + shorewall.conf. For run-time setting of shell + variables, use the init extension + script. If the params file needs to set shell variables based on the configuration of the firewall system, you can @@ -658,8 +633,7 @@ clean: /usr/share/shorewall-lite/shorecap > capabilities scp capabilities <admin system>:<this system's config dir> - Or, if you are running Shorewall 3.2.6 or later, simply use - the -c option the next time that you use the + Or simply use the -c option the next time that you use the reload command. @@ -738,9 +712,8 @@ CAPVERSION=40190 system with Shorewall installed and used when compiling firewall programs to run on the remote system. - Beginning with Shorewall Lite version 3.2.2, the - capabilities file may also be creating using - /sbin/shorewall-lite:
+ The capabilities file may also be creating + using /sbin/shorewall-lite:
shorewall-lite show -f capabilities > capabilities
@@ -790,4 +763,4 @@ CAPVERSION=40190 is the level specified in the shorewall.conf file used when the program was compiled.
- \ No newline at end of file + diff --git a/docs/Documentation_Index.xml b/docs/Documentation_Index.xml index 0ccbc9f89..d3e71f960 100644 --- a/docs/Documentation_Index.xml +++ b/docs/Documentation_Index.xml @@ -57,11 +57,10 @@ 6to4 Tunnels - Limiting per-IPaddress - Connection Rate + KVM (Kernel-mode Virtual + Machine) - Shorewall - Lite + @@ -69,8 +68,7 @@ Logging - Shorewall - Modularization + @@ -78,8 +76,8 @@ Macros - Shorewall 4.x -- - What's new + Shorewall + Lite @@ -351,11 +349,9 @@ - KVM (Kernel-mode Virtual - Machine) + - Scalability and - Performance + diff --git a/docs/FAQ.xml b/docs/FAQ.xml index eb5f6b123..03f401c69 100644 --- a/docs/FAQ.xml +++ b/docs/FAQ.xml @@ -37,9 +37,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.0 then please see the documentation for that release. @@ -83,12 +83,9 @@ (FAQ 37a) I just installed Shorewall on Debian and I can't find the sample configurations. - Answer: With Shorewall 3.x, the - samples are included in the shorewall documentation package and are + Answer: Beginning with + Shorewall 4.0, the samples are in the shorewall-common package and are installed in /usr/share/doc/shorewall/examples/. - Beginning with Shorewall 4.0, the samples are in the shorewall-common - package and are installed in /usr/share/doc/shorewall-common/examples/.
@@ -606,14 +603,7 @@ DNAT loc loc:192.168.1.5 tcp www - Using this technique, you will want to configure your DHCP/PPPoE/PPTP/… client to automatically restart Shorewall each - time that you get a new IP address. - If you are running Shorewall 3.2.6 on a Debian-based - system, the call to - find_first_interface_address in - /etc/shorewall/params must be preceded with - a load of the Shorewall function library:. /usr/share/shorewall/functions -ETH0_IP=`find_first_interface_address eth0` - + time that you get a new IP address. @@ -733,14 +723,6 @@ DNAT loc dmz:192.168.2.4 tcp 80 - and shorewall[-lite] restore. - - - If you are running Shorewall 3.2.6 on a Debian-based system, - the call to find_first_interface_address in - /etc/shorewall/params must be preceded with a - load of the Shorewall function library:. /usr/share/shorewall/functions -ETH0_IP=`find_first_interface_address eth0` -
@@ -1026,13 +1008,10 @@ to debug/develop the newnat interface. non-bridged traffic is not supported anymore. This kernel change, while necessary, means that Shorewall zones - may no longer be defined in terms of bridge ports. See the new Shorewall-shell bridging - documentation for information about configuring a - bridge/firewall under kernel 2.6.20 and later with Shorewall shell or - the Shorewall-perl bridging - documentation if you use Shorewall-perl - (highly-recommended). + may no longer be defined in terms of bridge ports. See the Shorewall-perl bridging + documentation for information about how to configure + bridge/firewalls. Following the instructions in the new bridging documentation will not prevent the above message from being issued. @@ -1312,11 +1291,11 @@ teastep@ursa:~$ The first number determines the maximum log rule to that effect. - Beginning with Shorewall 3.3.3, packets logged out of these - chains may have a source and/or destination that is not in any - defined zone (see the output of shorewall[-lite] show - zones). Remember that zone membership involves both a - firewall interface and an ip address. + Packets logged out of these chains may have a source and/or + destination that is not in any defined zone (see the output of + shorewall[-lite] show zones). Remember that + zone membership involves both a firewall interface and an ip + address. @@ -1392,10 +1371,10 @@ teastep@ursa:~$ The first number determines the maximum log or you've done something silly like define a default route out of an internal interface. - In Shorewall 3.3.3 and later versions with OPTIMIZE=1 in - shorewall.conf, - such packets may also be logged out of a <zone>2all chain or - the all2all chain. + With OPTIMIZE=1 in shorewall.conf, such + packets may also be logged out of a <zone>2all chain or the + all2all chain. @@ -1407,10 +1386,10 @@ teastep@ursa:~$ The first number determines the maximum log your defined zones(shorewall[-lite] show zones and look at the printed zone definitions). - In Shorewall 3.3.3 and later versions with OPTIMIZE=1 in - shorewall.conf, - such packets may also be logged out of the fw2all chain or the - all2all chain. + With OPTIMIZE=1 in shorewall.conf, such + packets may also be logged out of the fw2all chain or the all2all + chain. @@ -1770,21 +1749,6 @@ Creating input Chains... at the -I (--insert) command.
-
- (FAQ 34) How can I speed up Shorewall start (restart)? - - Answer: Switch to using Shorewall-perl. -
- -
- (FAQ 69) When I restart Shorewall, new connections are blocked - for a long time. Is there a way to avoid that? - - Answer: Switch to using Shorewall-perl. -
-
(FAQ 43) I just installed the Shorewall RPM and Shorewall doesn't start at boot time. @@ -1864,12 +1828,11 @@ iptables: Invalid argument - Beginning with Shorewall 3.4.0, Shorewall no longer attempts to - use policy match if you have no IPSEC zones and you have not specified - the option on any entry in - /etc/shorewall/hosts. The subject message will - still appear in your kernel log each time that Shorewall determines - the capabilities of your kernel/iptables. + Shorewall does not attempt to use policy match if you have no + IPSEC zones and you have not specified the + option on any entry in /etc/shorewall/hosts. The + subject message will still appear in your kernel log each time that + Shorewall determines the capabilities of your kernel/iptables.
@@ -2072,8 +2035,8 @@ We have an error talking to the kernel
(FAQ 12) Is there a GUI? - Answer: Yes! Shorewall 3.x - support is available in Webmin 1.300. See Answer: Yes! Shorewall support is + available in Webmin. See http://www.webmin.com
@@ -2106,16 +2069,6 @@ We have an error talking to the kernel type: /sbin/shorewall[-lite] version - -
- (FAQ 25a) How do I tell which version of Shorewall-perl and - Shorewall-shell that I have installed? - - Answer: At the shell prompt, - type: - - /sbin/shorewall version -a -
@@ -2211,8 +2164,8 @@ We have an error talking to the kernel with kernel 2.6.25. So that is what we developed IPv6 support on and that's all that it has been tested on. If you are running 2.6.20 or later, you can try to run Shorewall6 - by hacking /usr/share/shorewall-perl/prog.footer6 - and changing the kernel version test to check for your kernel version + by hacking /usr/share/shorewall/prog.footer6 and + changing the kernel version test to check for your kernel version rather than 2.6.25 (20625). But after that, you are on your own. @@ -2399,69 +2352,8 @@ eth0 eth1 # eth1 = interface to local netwo (FAQ 60) What are the compatibility restrictions between Shorewall and Shorewall Lite - Answer: Beginning with version - 3.2.3, there are no compatibility constraints between Shorewall and - Shorewall-lite. -
- - -
- Shorewall-Perl - -
- (FAQ 70) What is Shorewall-Perl? - - Answer: Shorewall-perl is a - re-implementation of the Shorewall configuration compiler written in - Perl. -
- -
- (FAQ 71) What are the advantages of using Shorewall-perl? - - Answer: - - - - The Shorewall-perl compiler is much faster than the - Shorewall-shell compiler. - - - - The script generated by the Shorewall-perl compiler uses - iptables-restore to instantiate the Netfilter - configuration. So it runs much faster than the script generated by - the Shorewall-shell compiler and doesn't disable new connections - during rule set installation. - - - - The Shorewall-perl compiler does more thorough checking of the - configuration than the Shorewall-shell compiler does. - - - - The error messages produced by the Shorewall-perl compiler are - better, more consistent and always include the file name and line - number where the error was detected. - - - - Going forward, the Shorewall-perl compiler will get all - enhancements; the Shorewall-shell compiler will only get those - enhancements that are easy to retrofit. - - -
- -
- (FAQ 72) Can I switch to using Shorewall-perl without changing my - Shorewall configuration? - - Answer: Maybe yes, maybe no. See - the Shorewall Perl article for - a list of the incompatibilities between Shorewall-shell and - Shorewall-perl. + Answer: There are no + compatibility constraints between Shorewall and Shorewall-lite.
diff --git a/docs/IPP2P.xml b/docs/IPP2P.xml index f30963f0e..96d08d296 100644 --- a/docs/IPP2P.xml +++ b/docs/IPP2P.xml @@ -41,26 +41,22 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. - - If you are running the xtables-addons version - of IPP2P, you are strongly advised to use Shorewall-perl 4.2.5 or - later.
Introduction - Shorewall versions 2.2.0 and later include support for the ipp2p - match facility. This is a departure from my usual policy in that the ipp2p - match facility is included in xtables-addons and is unlikely to ever be - included in the kernel.org source tree. Questions about how to install - xtables-addons or how to build your kernel and/or iptables should not be - posted on the Shorewall mailing lists but should rather be referred to the - Netfilter Mailing List. + Shorewall includes support for the ipp2p match facility. This is a + departure from my usual policy in that the ipp2p match facility is + included in xtables-addons and is unlikely to ever be included in the + kernel.org source tree. Questions about how to install xtables-addons or + how to build your kernel and/or iptables should not be posted on the + Shorewall mailing lists but should rather be referred to the Netfilter + Mailing List.
@@ -91,25 +87,11 @@ iptables -m ipp2p --help You must not include the leading "--" on the option(s); Shorewall - will supply those characters for you. If you do not include an option - then: + will supply those characters for you. If you do not include an option then + Shorewall will assume "edk,kazaa,gnu,dc". - - - Shorewall-shell and Shorewall-perl up through 4.2.4 will assume - "ipp2p". Note that the xtables-addons version of IPP2P no longer - supports that option. - - - - Shorewall-perl 4.2.5 and later will assume "ipp2p" if that - option is supported by the installed iptables/Netfilter. Otherwise, - Shorewall-perl will assume "edk,kazaa,gnu,dc" - - - - If 'ipp2p' is specified, Shorewall-perl 4.2.5 and later will - substitute "edk,kazaa,gnu,dc". + If 'ipp2p' is specified, Shorewall will substitute + "edk,kazaa,gnu,dc".
diff --git a/docs/IPSEC-2.6.xml b/docs/IPSEC-2.6.xml index 0e614bcf8..d6f13f974 100644 --- a/docs/IPSEC-2.6.xml +++ b/docs/IPSEC-2.6.xml @@ -51,9 +51,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. @@ -83,7 +83,7 @@
- Shorewall 3.0 and Kernel 2.6 IPSEC + Shorwall and Kernel 2.6 IPSEC This is not a HOWTO for Kernel 2.6 IPSEC -- for that, please see 2008 + 2009 + Thomas M. Eastep @@ -34,6 +36,13 @@ + + This article applies to Shorewall 4.3 and + later. If you are running a version of Shorewall earlier than Shorewall + 4.3.5 then please see the documentation for that + release. + +
Overview @@ -77,9 +86,8 @@ of /sbin/shorewall. /sbin/shorewall only handles IPv4 while /sbin/shorewall6 handles only IPv6.. Shorewall6 - depends on both Shorewall-common and on Shorewall-perl. The - Shorewall6 configuration is stored in /etc/shorewall6. + depends on Shorewall. The Shorewall6 configuration is stored in + /etc/shorewall6. @@ -476,11 +484,7 @@ ACCEPT net:wlan0:<2002:ce7c:92b4::3> tcp - Also, please note that since Shorewall6 is based on - Shorewall-perl, dynamic zones are not supported. Hence the add and - delete commands are not supported by - /sbin/shorewall6 and - /sbin/shorewall6-lite. + @@ -505,19 +509,15 @@ ACCEPT net:wlan0:<2002:ce7c:92b4::3> tcp - Shorewall-common 4.2.4 or later. + Shorewall 4.3.5 or later. - Shorewall-perl 4.2.4 or later. - - - - Shorewall6 4.2.4 or later. + Shorewall6 4.3.5 or later. - You may also with to install Shorewall6-lite 4.3.4 or later on your + You may also with to install Shorewall6-lite 4.3.5 or later on your remote firewalls to allow for central IPv6 firewall administration.
diff --git a/docs/Install.xml b/docs/Install.xml index cf19bbc07..03f7f7f92 100644 --- a/docs/Install.xml +++ b/docs/Install.xml @@ -22,6 +22,8 @@ 2006 + 2009 + Thomas M. Eastep @@ -37,9 +39,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are installing or upgrading to a version of Shorewall - earlier than Shorewall 3.0.0 then please see the documentation for that + earlier than Shorewall 4.3.5 then please see the documentation for that release. @@ -47,7 +49,9 @@ Before attempting installation, I strongly urge you to read and print a copy of the Shorewall QuickStart Guide for the configuration that most closely matches - your own. + your own. This article only tells you how to install the product on your + system. The QuickStart Guides describe how to configure the + product. @@ -91,27 +95,13 @@ page. If you try to install the wrong package, it probably won't - work. - If you are installing Shorewall 4.0.0 or later then you need - to install at least two packages. - - Either Shorewall-shell (the classic shell-based - configuration compiler) and/or Shorewall-perl (the newer and - faster compiler written in Perl). - - - - Shorewall-common - - If you are installing Shorewall for the first - time, we strongly suggest that you install Shorewall-perl. - + work. Install the RPMs - rpm -ivh <compiler rpm> ... <shorewall-common rpm> + rpm -ivh <shorewall rpm> Some users are in the habit of using the rpm @@ -123,15 +113,6 @@ links. - - 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 <rpms> - - Shorewall is dependent on the iproute package. Unfortunately, some distributions call this package iproute2 which will cause the @@ -146,39 +127,7 @@ rpm -ivh --nodeps <rpms> - Example:rpm -ivh shorewall-perl-4.0.0-1.noarch.rpm shorewall-common-4.0.0-1.noarch.rpm - Simon Matter names his 'common' rpm - 'shorewall' rather than - 'shorewall-common'. So if you are installing - his RPMs, the command would be:rpm -ivh shorewall-perl-4.0.0-1.noarch.rpm shorewall-4.0.0-1.noarch.rpm - - - - - Edit the configuration files - to match your configuration. - - - 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. - - - - - Enable startup by editing - /etc/shorewall/shorewall.conf and set - STARTUP_ENABLED to Yes). - - - - Start the firewall by typing - - shorewall start + Example:rpm -ivh shorewall-4.3.5-0base.noarch.rpm
@@ -186,35 +135,16 @@
Install using tarball - - If you are installing Shorewall 4.0.0 or later then you need to - install at least two packages. - - Either Shorewall-shell (the classic shell-based - configuration compiler) and/or Shorewall-perl (the newer and - faster compiler written in Perl). - - - - Shorewall-common - - If you are installing Shorewall for the first time, we - strongly suggest that you install Shorewall-perl. - - - To install Shorewall-perl and Shorewall-common using the tarball and - install scripts: + To install Shorewall using the tarball and install script: - unpack the tarballs:tar -jxf shorewall-common-4.0.0.tar.bz2 -tar -jxf shorewall-perl-4.0.0.tar.bz2 - + unpack the tarballs:tar -jxf shorewall-4.3.5.tar.bz2 - cd to the shorewall-perl directory (the version is encoded in - the directory name as in shorewall-perl-4.0.0). + cd to the shorewall directory (the version is encoded in the + directory name as in shorewall-4.3.5). @@ -223,34 +153,6 @@ ./install.sh - - cd to the shorewall-common directory (the version is encoded in - the directory name as in shorewall-common-4.0.0) - - - - Type: - - ./install.sh - - - - Edit the configuration files - to match your configuration. - - - - Enable Startup by editing - /etc/shorewall/shorewall.conf and set - STARTUP_ENABLED=Yes. - - - - Start the firewall by typing - - shorewall start - - If the install script was unable to configure Shorewall to be started automatically at boot, see /etc/apt/preferences: - Package: shorewall-common -Pin: release o=Debian,a=testing -Pin-Priority: 700 - -Package: shorewall-perl + Package: shorewall Pin: release o=Debian,a=testing Pin-Priority: 700 @@ -292,7 +190,7 @@ Package: shorewall-doc Pin: release o=Debian,a=testing Pin-Priority: 700Then run:# apt-get update -# apt-get install shorewall-common shorewall-perl +# apt-get install shorewall Once you have completed configuring Shorewall, you can enable startup at boot time by setting startup=1 in @@ -365,16 +263,7 @@ Pin-Priority: 700Then Upgrade the RPM - rpm -Uvh <compiler rpm file> ... <shorewall-common rpm file> - - - 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-common rpm> <compiler rpm> ... - + rpm -Uvh <shorewall rpm file> Shorewall is dependent on the iproute package. Unfortunately, @@ -386,7 +275,7 @@ Pin-Priority: 700Then This may be worked around by using the --nodeps option of rpm. - rpm -Uvh --nodeps <shorewall rpm> <compiler-rpm> ... + rpm -Uvh --nodeps <shorewall rpm> ... @@ -420,30 +309,12 @@ Pin-Priority: 700Then - unpack the tarballs:tar -jxf shorewall-common-4.0.0.tar.bz2 -tar -jxf shorewall-perl-4.0.0.tar.bz2 -tar -jxf shorewall-shell-4.0.0.tar.bz2 (if you use this compiler) + unpack the tarball:tar -jxf shorewall-4.3.5.tar.bz2 cd to the shorewall-perl directory (the version is encoded in - the directory name as in shorewall-perl-4.0.0). - - - - Type: - - ./install.sh - - - - Perform the above two steps for the shorewall-shell directory if - you use that compiler. - - - - cd to the shorewall-common directory (the version is encoded in - the directory name as in shorewall-perl-4.0.0) + the directory name as in shorewall-4.3.5). @@ -485,140 +356,6 @@ tar -jxf shorewall-shell-4.0.0.tar.bz2 (if you use this compiler)
-
- Upgrade the .lrp - - The following was contributed by Charles Steinkuehler on the Leaf - mailing list: - -
- It's *VERY* simple...just put in a new CD and reboot!  :-) - Actually, I'm only slightly kidding...that's exactly how I upgrade my - production firewalls.  The partial backup feature I added to Dachstein - allows configuration data to be stored separately from the rest of the - package. - - Once the config data is separated from the rest of the package, - it's an easy matter to upgrade the package while keeping your current - configuration (in my case, just inserting a new CD and - re-booting). - - Users who aren't running with multiple package paths and using - partial backups can still upgrade a package, it just takes a bit of - extra work.  The general idea is to use a partial backup to save your - configuration, replace the package, and restore your old configuration - files. Step-by-step instructions for one way to do this (assuming a - conventional single-floppy LEAF system) would be: - - - - Make a backup copy of your firewall disk ('NEW').  This is the - disk you will add the upgraded package(s) to. - - - - Format a floppy to use as a temporary location for your - configuration file(s) ('XFER').  This disk should have the same - format as your firewall disk (and could simply be another backup - copy of your current firewall). - - - - Make sure you have a working copy of your existing firewall - ('OLD') in a safe place, that you *DO NOT* use during this process. - That way, if anything goes wrong you can simply reboot off the OLD - disk to get back to a working configuration. - - - - Remove your current firewall configuration disk and replace it - with the XFER disk. - - - - Use the lrcfg backup menu to make a partial backup of the - package(s) you want to upgrade, being sure to backup the files to - the XFER disk.  From the backup menu: - - t e <enter> p <enter> -b <package1> <enter> -b <package2> <enter> -... - - - - Download and copy the package(s) you want to upgrade onto the - NEW disk. - - - - Reboot your firewall using the NEW disk...at this point your - upgraded packages will have their default configuration. - - - - Mount the XFER disk (mount -t msdos /dev/fd0u1680 /mnt) - - - - CD to the root directory (cd /) - - - - Manually extract configuration data for each package you - upgraded: - - tar -xzvf /mnt/package1.lrp -tar -xzvf /mnt/package2.lrp -... - - - - Unmount (umount /mnt) and remove the XFER disk - - - - Using lrcfg, do *FULL* backups of your upgraded - packages. - - - - Reboot, verifying the firewall works as expected.  Some - configuration files may need to be 'tweaked' to work properly with - the upgraded package binaries. - - - - - The new package file <package>.local can be used to - fine-tune which files are included (and excluded) from the partial - backup (see the Dachstein-CD README for details).  If this file - doesn't exist, the backup scripts assume anything from the - <package>.list file that resides in /etc or /var/lib/lrpkg is - part of the configuration data and is used to create the partial - backup.  If shorewall puts anything in /etc that isn't a user modified - configuration file, a proper shorewall.local file should be created - prior to making the partial backup [Editor's - note: Shorewall places only user-modifiable files in - /etc]. - - - - It's obviously possible to do the above 'in-place', without - using multiple disks, and even without making a partial backup (ie: - copy current config files to /tmp, manually extract new package on top - of current running firewall, then copy or merge config data from /tmp - and backup...or similar), but anyone capable of that level of command - line gymnastics is probably doing it already, without needing detailed - instructions! :-) - -
- - For information on other LEAF/Bering upgrade tools, check out this - article by Alex Rhomberg. -
-
Configuring Shorewall diff --git a/docs/Introduction.xml b/docs/Introduction.xml index 2e1609e02..9f08094f7 100644 --- a/docs/Introduction.xml +++ b/docs/Introduction.xml @@ -16,7 +16,7 @@ - 2003-2007 + 2003-2009 Thomas M. Eastep @@ -35,8 +35,8 @@
Introduction - The information in this document applies only to 4.x releases of - Shorewall. + The information in this document applies only to 4.3 and later + releases of Shorewall.
Glossary @@ -337,12 +337,11 @@ ACCEPT net $FW tcp 22
Compile then Execute - Shorewall versions beginning with 3.2.0 use a "compile" then - "execute" approach. The Shorewall configuration compiler reads the - configuration files and generates a shell script. Errors in the - compilation step cause the script to be discarded and the command to be - aborted. If the compilation step doesn't find any errors then the shell - script is executed. + Shorewall uses a "compile" then "execute" approach. The Shorewall + configuration compiler reads the configuration files and generates a shell + script. Errors in the compilation step cause the script to be discarded + and the command to be aborted. If the compilation step doesn't find any + errors then the shell script is executed. The 'compiled' scripts are placed in the directory /var/lib/shorewall and are named to @@ -355,54 +354,37 @@ ACCEPT net $FW tcp 22
Shorewall Packages - Shorewall 4.0 consists of four packages. + Shorewall 4.3 and later consists of four packages. - Shorewall-common. This package - must be installed on at least one system in your network. That system - must also have Shorewall-shell and/or Shorewall-perl installed. + Shorewall. This package must be + installed on at least one system in your network. It contains + everything needed to create an IPv4 firewall. - Shorewall-shell. This package - includes the legacy Shorewall configuration compiler written in Bourne - Shell. This compiler is very portable but suffers from performance - problems and has become hard to maintain. - - - - Shorewall-perl. An alternative - to Shorewall-shell written in the Perl language. This compiler is - highly portable to those Unix-like platforms that support Perl - (including Cygwin) and is the compiler of choice for new Shorewall - installations. Scripts created using Shorewall-perl use - iptables-restore to install the generated Netfilter rule set. + Shorewall6. This package + requires the Shorewall package and adds those components needed to + create an IPv6 fireawall. Shorewall-lite. Shorewall - allows for central administration of multiple firewalls through use of - Shorewall lite. The full Shorewall product (along with Shorewall-shell - and/or Shorewall-perl) are installed on a central administrative - system where compiled Shorewall scripts are generated. These scripts - are copied to the firewall systems where they run under the control of - Shorewall-lite. - - - - In Shorewall 4.2.4, two additional packages were added: - - - - Shorewall6 - The utilities - necessary to control and configure an - IPv6 firewall. + allows for central administration of multiple IPv4 firewalls through + use of Shorewall lite. The full Shorewall product is installed on a + central administrative system where compiled Shorewall scripts are + generated. These scripts are copied to the firewall systems where they + run under the control of Shorewall-lite. - Shorewall6-lite - The IPv6 - equivalent of Shorewall-lite. + Shorewall6-lite. Shorewall + allows for central administration of multiple IPv4 firewalls through + use of Shorewall lite. The full Shorewall product is installed on a + central administrative system where compiled Shorewall scripts are + generated. These scripts are copied to the firewall systems where they + run under the control of Shorewall-lite.
diff --git a/docs/MAC_Validation.xml b/docs/MAC_Validation.xml index b0a2ffe1c..3c09151bd 100644 --- a/docs/MAC_Validation.xml +++ b/docs/MAC_Validation.xml @@ -86,9 +86,9 @@ The maclist option in /etc/shorewall/hosts. When this - option is specified for a subnet, all new connection requests from - that subnet are subject to MAC verification. + url="manpages/shorewall-hosts.html">/etc/shorewall/hosts. When + this option is specified for a subnet, all new connection requests + from that subnet are subject to MAC verification. @@ -110,10 +110,9 @@ - Beginning with Shorewall 2.2.3, the MACLIST_TTL variable in /etc/shorewall/shorewall.conf. The performance of - configurations with a large numbers of entries in + The MACLIST_TTL variable in + /etc/shorewall/shorewall.conf. The + performance of configurations with a large numbers of entries in /etc/shorewall/maclist can be improved by setting the MACLIST_TTL variable. @@ -138,9 +137,8 @@ - Beginning with Shorewall 2.4.6, the MACLIST_TABLE variable in /etc/shorewall/shorewall.conf. Normally, MAC + The MACLIST_TABLE variable in + /etc/shorewall/shorewall.conf. Normally, MAC verification occurs in the filter table (INPUT and FORWARD) chains. When forwarding a packet from an interface with MAC verification to a bridge interface, that doesn't work. @@ -161,7 +159,7 @@ - DISPOSITION (Added in Shorewall version 3.1) + DISPOSITION Must be ACCEPT, DROP or REJECT (REJECT may not be specified if @@ -186,9 +184,9 @@ The MAC address of a device on the Ethernet segment connected by INTERFACE. It is not necessary to use the Shorewall MAC format in - this column although you may use that format if you so choose. - Beginning with Shorewall 3.1, you may specify "-" here if you enter - an IP address in the next column. + this column although you may use that format if you so choose. You + may specify "-" here if you enter an IP address in the next + column. diff --git a/docs/Macros.xml b/docs/Macros.xml index 36eb914ea..6f860ca4c 100644 --- a/docs/Macros.xml +++ b/docs/Macros.xml @@ -41,9 +41,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. @@ -112,33 +112,9 @@ PARAM - - tcp 135,139,445 when you invoke the macro. The SMB macro shown above is parameterized (note PARAM in the TARGET column). - Shorewall versions prior to 4.2.0: - When invoking a parameterized macro, you follow the name of the macro with - a slash ("/") and the action that you want to substitute for PARAM. - - Example: - -
- /etc/shorewall/rules: - - #ACTION SOURCE DEST PROTO DEST PORT(S) -SMB/ACCEPT loc fw - - The above is equivalent to coding the following series of - rules: - - #TARGET SOURCE DEST PROTO DEST PORT(s) -ACCEPT loc fw udp 135,445 -ACCEPT loc fw udp 137:139 -ACCEPT loc fw udp 1024: 137 -ACCEPT loc fw tcp 135,139,445 -
- - Shorewall-perl versions 4.2.0 and - later: When invoking a parameterized macro, you follow the name - of the macro with the action that you want to substitute for PARAM - enclosed in parentheses. The older syntax described above is still - supported but is deprecated. + When invoking a parameterized macro, you follow the name of the + macro with the action that you want to substitute for PARAM enclosed in + parentheses. Example: @@ -168,11 +144,10 @@ ACCEPT loc fw tcp 135,139,445 If a value other than "-" appears in both the macro body and in the invocation of the macro, then the value in the invocation is - examined and the appropriate action is taken (you will want to be - running Shorewall 3.0.1 or later). If the value in the invocation - appears to be an address (IP or MAC) or the name of an ipset, then - it is placed after the value in the macro body. Otherwise, it is - placed before the value in the macro body. + examined and the appropriate action is taken. If the value in the + invocation appears to be an address (IP or MAC) or the name of an + ipset, then it is placed after the value in the macro body. + Otherwise, it is placed before the value in the macro body. Example 1: @@ -224,16 +199,16 @@ SMTP(DNAT):info net loc DNAT:info net loc:192.168.1.5 tcp 25 - Beginning with Shorewall 3.1, you may also specify SOURCE or - DEST in the SOURCE and DEST columns. This allows you to define - macros that work in both directions. + You may also specify SOURCE or DEST in the SOURCE and DEST + columns. This allows you to define macros that work in both + directions. Example 3:
/etc/shorewall/macro.SMBBI (Note: there - is already a macro like this released as part of Shorewall 3.1 and - later): + is already a standard macro like this released as part of + Shorewall): #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP @@ -287,32 +262,6 @@ ACCEPT fw loc tcp 135,139,445 from actions cannot themselves invoke other actions.
-
- Default Macros - - Beginning with Shorewall release 3.4, Shorewall supports - default macros; default macros perform the same - function as default actions. The DEFAULT_ACCEPT, - DEFAULT_REJECT, DEFAULT_DROP and DEFAULT_QUEUE options in - /etc/shorewall/shorewall.conf may specify the name of - a macro. In that case, the rules in the macro will be traversed before the - associated policy is applied. - - The value of the …_DEFAULT settings is interpreted as follows. If - USE_ACTIONS=Yes in shorewall.conf, then the value is treated like the name - of an action -- if that action is not found, then the value is treated - like the name of a macro. If USE_ACTIONS=No, then the value is treated - like the name of a macro. The special value "none" is always interpreted - as "no default rules should be applied". - - Shorewall versions 3.4 and later include standard 'Reject' and - 'Drop' macros that are equivalent to the 'Reject' and 'Drop' - actions. - - Default Macros are not supported by - Shorewall-perl. -
-
Defining your own Macros diff --git a/docs/ManualChains.xml b/docs/ManualChains.xml index d7e492fe2..9e7cfd29a 100644 --- a/docs/ManualChains.xml +++ b/docs/ManualChains.xml @@ -18,7 +18,9 @@ - 2007 + 2008 + + 2009 Thomas M. Eastep @@ -37,10 +39,10 @@
Introduction - Manual chains were introduced in Shorewall-perl 4.0.6; for Perl - programmers, manual chains provide an alternative to Actions with - extension scripts. Manual chains are chains which you create and populate - yourself using the low-level functions in Shorewall::Chains. + For Perl programmers, manual chains provide an alternative to + Actions with extension scripts. Manual chains are chains which you create + and populate yourself using the low-level functions in + Shorewall::Chains. Manual chains work in conjunction with the compile - -
- - - - Shorewall Modularization - - - - Tom - - Eastep - - - - - - - 2006 - - Thomas M. Eastep - - - - Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 1.2 or any later version published by the Free Software 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. - - - -
- Introduction - - One of the major changes in Shorewall version 3.4 involved breaking - much of the code into libraries. This - modularization is expected to be used primarily by embedded distributions - that wish to minimize the Shorewall disk and RAM footprint. - - Shorewall libraries are Bourne shell source files that contain - nothing but function declarations. Shorewall libraries may be loaded into - a running shell program using the shell's "." operator. The library files - have names which begin with "lib." and are installed in /usr/share/shorewall/. - - Individual libraries are of one of two classes. The first class of - libraries are required libraries which, as their - name implies, must be included in any Shorewall installation. The other - libraries are optional libraries that implement a - particular function. Each optional library may be included or omitted - based on the requirements of the individual installation. -
- -
- Required Libraries - - Shorewall 3.4 includes the following required libraries. - - - - lib.base — includes functions needed by all Shorewall - programs. - - - - lib.cli — includes functions common to both - /sbin/shorewall and - /sbin/shorewall-lite. - - - - lib.config — contains functions common to both - /sbin/shorewall and - /usr/share/shorewall/firewall. - - - - lib.base and lib.cli are installed in /usr/share/shorewall-lite/ on - Shorewall Lite systems. -
- -
- Optional Libraries - - Optional libraries are loaded upon demand based on the user's - configuration. - - In Shorewall 3.4, the optional libraries are as follows. - - - - lib.accounting — required if the - /etc/shorewall/accounting file is - non-empty. - - - - lib.actions — required if USE_ACTIONS=Yes in - /etc/shorewall/shorewall.conf. - - - - lib.dynamiczones — required if DYNAMIC_ZONES=Yes in - /etc/shorewall/shorewall.conf. - - - - lib.maclist — required if the maclist option is specified in any - entry in /etc/shorewall/interfaces or - /etc/shorewall/hosts. - - - - lib.nat — required if the - /etc/shorewall/masq, - /etc/shorewall/nat or - /etc/shorewall/netmap files are non-empty or if - DNAT[-] rules are present in - /etc/shorewall/rules. - - - - lib.providers — required if the - /etc/shorewall/providers file is - non-empty. - - - - lib.proxyarp — required if the - /etc/shorewall/proxyarp file is non-empty or if - the proxyarp option is specified in - an entry in /etc/shorewall/interfaces. - - - - lib.tc — required if the - /etc/shorewall/tcdevices or - /etc/shorewall/tcclasses file is - non-empty. - - - - lib.tcrules — required if the - /etc/shorewall/tcrules file is non-empty. - - - - lib.tunnels — required if the - /etc/shorewall/tunnels file is - non-empty. - - - - As described, many of the libraries are required when one or more - configuration files are non-empty and embedded distribution providers are - encouraged to package each optional library together with its associated - configuration files. - - - - - - - - Library - - Files - - - - lib.accounting - - /etc/shorewall/accounting - - - - lib.actions - - /etc/shorewall/actions - - - - lib.maclist - - /etc/shorewall/maclist - - - - lib.nat - - /etc/shorewall/masq, /etc/shorewall/nat, - /etc/shorewall/netmap - - - - lib.providers - - /etc/shorewall/route_rules, - /etc/shorewall/providers - - - - lib.proxyarp - - /etc/shorewall/proxyarp - - - - lib.tc - - /etc/shorewall/tcclasses, - /etc/shorewall/tcdevices - - - - lib.tcrules - - /etc/shorewall/tcrules - - - - lib.tunnels - - /etc/shorewall/tunnels - - - - - - Note that in Shorewall 4, the optional libraries (with the exception - of lib.dynamiczones) are included in the - Shorewall-shell package while the required libraries and - lib.dynamiczones are included in the Shorewall-common - package. -
-
diff --git a/docs/MultiISP.xml b/docs/MultiISP.xml index 26574a4f7..03698cf3d 100644 --- a/docs/MultiISP.xml +++ b/docs/MultiISP.xml @@ -43,9 +43,9 @@ - This document describes the Multi-ISP facility in Shorewall 4.0 and - later. If you are running an earlier release, please see the documentation - for that release. + This document describes the Multi-ISP facility in Shorewall 4.3.5 + and later. If you are running an earlier release, please see the + documentation for that release. @@ -76,14 +76,13 @@
Multiple Internet Connection Support - Beginning with Shorewall 2.3.2, limited support is included for - multiple Internet connections. Limitations of this support are as - follows: + Shorewall includes limited support for multiple Internet + connections. Limitations of this support are as follows: - It utilizes static routing configuration. As such, there is no - provision for reacting to the failure of any of the uplinks. + It utilizes static routing configuration. If there is a change + in the routing topopogy, Shorewall must be restarted. @@ -94,13 +93,6 @@ filter should have no effect on routing. - - Prior to Shorewall 3.4.0, the routes and route rules added by - this support were not completely removed during shorewall - stop, shorewall clear or - shorewall restart. - - For most routing applications, Quagga is a better solution @@ -226,8 +218,7 @@ value and will restore the packet mark in the PREROUTING CHAIN. Mark values must be in the range 1-255. - Beginning with Shorewall version 3.2.0 Beta 6, you may use - may set HIGH_ROUTE_MARKS=Yes in + Alternatively, you may set HIGH_ROUTE_MARKS=Yes in /etc/shorewall/shorewall.conf. This allows you to: @@ -417,7 +408,7 @@ - optional (added in Shorewall 3.2.2) + optional Shorewall will determine of this interface is up and @@ -432,8 +423,7 @@ without error doesn't mean that traffic can actually be sent through the interface. - Beginning with Shorewall-perl 4.0.3, you can supply - an 'isusable' You can supply an 'isusable' extension script to extend Shorewall's interface state detection. @@ -442,8 +432,7 @@ - src=source-address (Added in - Shorewall-perl 4.1.5) + src=source-address Specifies the source address to use when routing to @@ -457,8 +446,7 @@ - mtu=number (Added in - Shorewall-perl 4.1.5) + mtu=number Specifies the MTU when forwarding through this @@ -469,8 +457,7 @@ fallback[=weight] - (Added in Shorewall-perl 4.2.5) + role="bold">fallback[=weight] Indicates that a default route through the provider @@ -764,10 +751,7 @@ eth1 eth2 130.252.99.27 Now suppose that you want to route all outgoing SMTP traffic from your local network through ISP 2. You would make this entry in /etc/shorewall/tcrules (and if you are - running a version of Shorewall earlier than 3.0.0, you would set - TC_ENABLED=Yes in /etc/shorewall/shorewall.conf). + url="traffic_shaping.htm">/etc/shorewall/tcrules #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) @@ -863,12 +847,11 @@ eth3 eth2 16.105.78.4
/etc/shorewall/route_rules - The /etc/shorewall/route_rules file was added - in Shorewall version 3.2.0. The route_rules file - allows assigning certain traffic to a particular provider just as - entries in the tcrules file. The difference between - the two files is that entries in route_rules are - independent of Netfilter. + The route_rules file allows assigning certain + traffic to a particular provider just as entries in the + tcrules file. The difference between the two files + is that entries in route_rules are independent of + Netfilter.
Routing Rules @@ -995,8 +978,7 @@ gateway:~ #Note that because we used a priority of 1000, the
USE_DEFAULT_RT - Beginning with Shorewall 4.2.0 Beta3, Shorewall-perl has supported - a USE_DEFAULT_RT option in USE_DEFAULT_RT is an option in shorewall.conf (5). One of the drawbacks of the Multi-ISP support as described in the @@ -1041,10 +1023,9 @@ gateway:~ #Note that because we used a priority of 1000, the All provider gateways must be specified explicitly in the GATEWAY column. 'detect' may not be specified. Note that for ppp interfaces, the GATEWAY may remain unspecified ("-"). - Beginning with Shorewall 4.2.6, 'detect' may be specified - for interfaces whose configuration is managed by dhcpcd. - Shorewall will use dhcpcd's database to determine the gateway IP - address. + 'detect' may be specified for interfaces whose + configuration is managed by dhcpcd. Shorewall will use dhcpcd's + database to determine the gateway IP address. @@ -1084,19 +1065,15 @@ shorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional<
SWPING - Beginning with Shorewall 4.2.6, Shorewall includes a sample - monitoring script swping. The - swping file is available in the main directory - contained in the Shorewall-common tarball and is included in the - Shorewall-common documentation directory on the Shorewall-common RPM. - The script is inspired by Angsuman Chakraborty's Shorewall includes a sample monitoring script + swping. The swping file is + available in the main directory contained in the Shorewall-common + tarball and is included in the Shorewall-common documentation + directory on the Shorewall-common RPM. The script is inspired by + Angsuman Chakraborty's gwping script. - For those not on 4.2.6 yet, the script may be downloaded from - http://www.shorewall.net/pub/shorewall/contrib/MultiISP-failover/. - These samples are offered as is — they work for me but I don't make any claim that they will work for @@ -1411,8 +1388,7 @@ exit 0;
Two Providers Sharing an Interface - Shared interface support is available only in Shorewall-perl 4.2.0 - and later. + Shared interface support has the following characteristics" @@ -1685,10 +1661,10 @@ wlan0 192.168.0.0/24 ROUTE_FILTER=No RESTORE_DEFAULT_ROUTE=No - The RESTORE_DEFAULT_ROUTE option was added in Shorewall-perl 4.2.6 - and causes the default route in the main table to be deleted when the - Comcast link is unavailable. That way, the default route in the default - table will be used until Comcast is available again. + RESTORE_DEFAULT_ROUTE=No causes the default route in the main table + to be deleted when the Comcast link is unavailable. That way, the default + route in the default table will be used until Comcast is available + again. /etc/shorewall/providers: diff --git a/docs/Multiple_Zones.xml b/docs/Multiple_Zones.xml index e582a6806..497a06a19 100644 --- a/docs/Multiple_Zones.xml +++ b/docs/Multiple_Zones.xml @@ -35,9 +35,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. diff --git a/docs/NAT.xml b/docs/NAT.xml index b21596bf8..e683c6775 100644 --- a/docs/NAT.xml +++ b/docs/NAT.xml @@ -35,9 +35,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. @@ -48,7 +48,8 @@ If all you want to do is forward ports to servers behind your firewall, you do NOT want to use one-to-one NAT. Port forwarding can be accomplished with simple entries in the rules file. + url="manpages/shorewall-rules.html">rules + file. One-to-one NAT is a way to make systems behind a firewall and @@ -114,8 +115,8 @@ yes or Yes (and the ALL INTERFACES COLUMN also contains Yes or yes) then such packets are redirected; otherwise, such packets are not redirected. This - feature requires 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. + feature requires that you enabled CONFIG_IP_NF_NAT_LOCAL in your + kernel. Entries in /etc/shorewall/nat only arrange for diff --git a/docs/PortKnocking.xml b/docs/PortKnocking.xml index 809cc0d4b..24ac7ecfe 100644 --- a/docs/PortKnocking.xml +++ b/docs/PortKnocking.xml @@ -89,20 +89,7 @@ Create /etc/shorewall/SSHKnock with the following - contents. - - If using Shorewall-shell: - - if [ -n "$LEVEL" ]; then - log_rule_limit $LEVEL $CHAIN SSHKnock ACCEPT "" "$TAG" -A -p tcp --dport 22 -m recent --rcheck --name SSH - log_rule_limit $LEVEL $CHAIN SSHKnock DROP "" "$TAG" -A -p tcp --dport ! 22 -fi -run_iptables -A $CHAIN -p tcp --dport 22 -m recent --rcheck --seconds 60 --name SSH -j ACCEPT -run_iptables -A $CHAIN -p tcp --dport 1599 -m recent --name SSH --remove -j DROP -run_iptables -A $CHAIN -p tcp --dport 1600 -m recent --name SSH --set -j DROP -run_iptables -A $CHAIN -p tcp --dport 1601 -m recent --name SSH --remove -j DROP - - If using Shorewall-perl:use Shorewall::Chains; + contents.use Shorewall::Chains; if ( $level ) { log_rule_limit( $level, @@ -148,10 +135,9 @@ SSHKnock:info net $FW tcp 22,1599,1600,1601< - If you wish to use SSHKnock with a forwarded connection, you - must be using Shorewall 2.3.1 or later for fullest protection. Assume - that you forward port 22 from external IP address 206.124.146.178 to - internal system 192.168.1.5. In /etc/shorewall/rules: + Assume that you forward port 22 from external IP address + 206.124.146.178 to internal system 192.168.1.5. In + /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST diff --git a/docs/ScalabilityAndPerformance.xml b/docs/ScalabilityAndPerformance.xml deleted file mode 100644 index bb0447ada..000000000 --- a/docs/ScalabilityAndPerformance.xml +++ /dev/null @@ -1,212 +0,0 @@ - - -
- - - - Scalability and Performance - - - - Tom - - Eastep - - - - - - - 2006 - - 2007 - - Thomas M. Eastep - - - - Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 1.2 or any later version published by the Free Software 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. - - - -
- Introduction - - The performance of the shorewall - start and shorewall restart - commands when using Shorewall-shell is a frequent topic of questions. This - article attempts to explain the scalability issues involved and to offer - some tips for reducing the time required to compile a Shorewall - configuration and to execute the compiled script. - - Ultimately, the solution to these performance problems is to migrate - to the use of Shorewall-perl if at all possible. -
- -
- Host Groups - - In this article, we will use the term host - group to refer to a set of IP addresses accessed through a - particular interface. In a Shorewall configuration, there is one host - group for: - - - - Each entry in /etc/shorewall/interfaces - that contains the name of a zone in the first column. - - - - Each entry in /etc/shorewall/hosts. - - - - As you can see, each host group is associated with a single - zone. -
- -
- Scaling by Host Groups - - For each host group, it is possible to attempt connections to every - other host group; and if the host group has the routeback option, then it is possible for - connections to be attempted from the host group to itself. So if there are - H host groups defined in a Shorewall - configuration, then the number of unique pairs of (source host - group, destination host group) is - H*H or - H2. In other - words, the number of combinations is the square of the number of host - groups and increasing the number of groups from H to H+1 adds - H + H + - 1 = 2H + 1 additional - combinations. -
- -
- Scaling by Zones - - A similar scaling issue applies to Shorewall zones. If there are - Z zones, then connections may be - attempted from a given zone Zn to all of the other zones - (including to Zn - itself). Hence, the number of combinations is the square of the number of - zones or Z2. -
- -
- Scaling within the Shorewall Code - - Shorewall-shell is written entirely in Bourne Shell. While this - allows Shorewall to run on a wide range of distributions (included - embedded ones), the shell programming environment is not ideal for writing - the compiler portion of Shorewall. As a consequence, the code must - repeatedly perform sequential searches of lists. If a list has N elements and a sequential search is made for each - of those elements, then the number of comparisons is 1 + 2 + 3 + .... + - N = N * - (N + 1 ) / 2. So again, we see order - N2 - scaling. -
- -
- Improving Performance - - Achieving good performance boils down to three things: - - - - Use a light-weight shell and fast hardware. Especially in the - compiler, a light-weight shell such as ash or - dash can provide considerable improvement over - bash. - - - - With all of the order N2 scaling that is - implicit in the problem being solved, it is vital to keep N small. - - - - If you have a large number of interfaces, use wild-cards - ("+") in /etc/shorewall/interfaces and - /etc/shorewall/hosts to reduce the number of - host groups. - - - - Combine host groups with similar firewall requirements into - a single zone. - - - - - - Use NONE policies wherever appropriate. This helps especially in - the rules activation phase of both script compilation and - execution. - - - - So while it is tempting to create lots of zones through entries in - /etc/shorewall/hosts, such configurations - always perform badly. In these cases, it is much - better to have more rules than more zones because the performance scales - linearly with the number of rules whereas it scales geometrically with the - number of zones. - - Another tip worth noting has to do with the use of shell - variables. - - Suppose that the following appears in - /etc/shorewall/params: - - HOSTS=<ip1>,<ip2>,<ip3>,...<ipN> - - and suppose that $HOSTS appears in the SOURCE column of M ACCEPT rules. That would generate a total of - N * M - iptables ACCEPT rules. - - The number of rules can be reduced significantly by using an action. Consider the following: - -
- /etc/shorewall/actions: - - AcceptHosts - - /etc/shorewall/action.AcceptHosts: - - #TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE -# PORT PORT(S) DEST LIMIT -ACCEPT $HOSTS -
- - If the M ACCEPT rules are now - replaced with M AcceptHosts rules, the - total number of rules will be N + - M. - - Example (Accept net->fw SSH from $HOSTS): - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ -# PORT PORT(S) DEST LIMIT GROUP -AcceptHosts net $FW tcp 22 -
-
\ No newline at end of file diff --git a/docs/Shorewall-4.xml b/docs/Shorewall-4.xml deleted file mode 100644 index b9ccd78a3..000000000 --- a/docs/Shorewall-4.xml +++ /dev/null @@ -1,238 +0,0 @@ - - -
- - - - Shorewall Version 4 - - - - Tom - - Eastep - - - - - - - 2007 - - 2009 - - Thomas M. Eastep - - - - Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 1.2 or any later version published by the Free Software 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. - - - -
- Introduction - - Shorewall version 4 represents a substantial shift in direction for - Shorewall. Up to now - - - - Shorewall has been written entirely in Bourne Shell. - - - - Shorewall has run the iptables utility to add - each Netfilter rule. - - - - Shorewall version 4 offers you a choice. You can continue to use the - existing shell-based implementation or you can use a new implementation of - the Shorewall compiler written in the Perl programming language. The new - compiler: - - - - has a small disk footprint - - - - is very fast. - - - - generates a firewall script that uses - iptables-restore; so the script is very - fast. - - - - generates better and more consistent error messages. - - - - does a much more thorough job of checking the configuration to - avoid run-time errors. - - - - supports creating either Ipv4 or Ipv6 firewalls (Shorewall 4.2.4 - and later). - - - - Both compilers may be installed on your system and you can use - whichever one suits you in a particular case. -
- -
- Installing Shorewall Version 4 - - Shorewall 4 contains six packages: - - - - Shorewall-shell - the old - shell-based compiler and related components. - - - - Shorewall-perl - the new - Perl-based compiler. - - - - Shorewall-common - the part of - Shorewall common to both compilers. - - - - Shorewall-lite- same as the 3.4 - version of Shorewall Lite. Can run scripts generated by either - Shorewall-perl or Shorewall-shell. - - - - Shorewall6 - The utilities for - creating and operating an Ipv6 firewall. Requires Shorewall-perl and - Shorewall-common. - - - - Shorewall6-lite - Ipv6 - equivalent of Shorewall Lite. Can run scripts generated by - Shoreall-perl 4.2.4 and later. - - - - If you upgrade to Shorewall Version 4, you must install - Shorewall-shell and/or Shorewall-perl; in fact, if you are using the - tarball for your installation, you must install Shorewall-shell and/or - Shorewall-perl before you upgrade - Shorewall. See the upgrade issues - for details. -
- -
- Prerequisites for using the Shorewall Version 4 Perl-based - Compiler - - - - Perl (I use Perl 5.8.8 but other 5.8 versions should work fine). - - If you want to be able to use DNS names in your Shorewall6 - configuration files, then Perl 5.10 is required together with the - Perl Socket6 module. - - - - - Perl Cwd Module - - - - Perl File::Basename - Module - - - - Perl File::Temp Module - - - - Perl Getopt::Long Module - - - - Perl Carp Module - - - - Perl FindBin Module (Shorewall - 4.0.3 and later) - - - - Perl Scalar::Util Module - (Shorewall 4.0.6 and later) - - -
- -
- Incompatibilities Introduced in the Shorewall Version 4 Perl-based - Compiler - - The Shorewall-perl compiler is not 100% compatible with the - Shorewall-shell version. See this - document for details. -
- -
- Compiler Selection - - If you only install one compiler, then that compiler will be - used. - - If you install both compilers, then the compiler actually used for - IPv4 depends on the SHOREWALL_COMPILER setting in - shorewall.conf. - - The value of this new option can be either 'perl' or 'shell'. - - If you add 'SHOREWALL_COMPILER=perl' to - /etc/shorewall/shorewall.conf then by default, the - new compiler will be used on the system. If you add it to - shorewall.conf in a separate directory (such as a - Shorewall-lite export directory) then the new compiler will only be used - when you compile from that directory. - - If you only install one compiler, it is suggested that you do not - set SHOREWALL_COMPILER. - - If both compilers are installed, you can select the compiler to use - on the command line using the 'C option: - '-C shell' means use the shell compiler - - '-C perl' means use the perl compiler - The -C option overrides the setting in - shorewall.conf. - - Example:shorewall restart -C perl - - When the Shorewall-perl compiler has been selected, the - params file is processed using the shell - option which causes all variables set within the file - to be exported automatically by the shell. The Shorewall-perl compiler - uses the current environmental variables to perform variable expansion - within the other Shorewall configuration files. -
-
diff --git a/docs/Shorewall-perl.xml b/docs/Shorewall-perl.xml index b2004b526..f22c81e17 100644 --- a/docs/Shorewall-perl.xml +++ b/docs/Shorewall-perl.xml @@ -20,6 +20,8 @@ 2007 + 2009 + Thomas M. Eastep @@ -37,43 +39,47 @@
Shorewall-perl - What is it? - Shorewall-perl is a companion product to Shorewall. + Shorewall-perl was released as a companion product to Shorewall in + Shorewall 4.0.0. - Shorewall-perl contains a re-implementation of the Shorewall + Shorewall-perl contained a re-implementation of the Shorewall compiler written in Perl. The advantages of using Shorewall-perl over Shorewall-shell (the shell-based compiler included in earlier Shorewall - 3.x releases) are: + 3.x releases) were: - The Shorewall-perl compiler is much faster. + The Shorewall-perl compiler was much faster. - The script generated by the compiler uses + The script generated by the compiler used iptables-restore to instantiate the Netfilter - configuration. So it runs much faster than the script generated by the - Shorewall-shell compiler and doesn't stop new connections during + configuration. So it ran much faster than the script generated by the + Shorewall-shell compiler and did not stop new connections during shorewall restart. - The Shorewall-perl compiler does more thorough checking of the - configuration than the Shorewall-shell compiler does. + The Shorewall-perl compiler did more thorough checking of the + configuration than the Shorewall-shell compiler did. - The error messages produced by the compiler are better, more - consistent and always include the file name and line number where the + The error messages produced by the compiler were better, more + consistent and always included the file name and line number where the error was detected. - Going forward, the Shorewall-perl compiler will get all - enhancements; the Shorewall-shell compiler will only get those - enhancements that are easy to retrofit. + Going forward, the Shorewall-perl compiler got all enhancements; + the Shorewall-shell compilerl only got those enhancements that were + easy to retrofit. + + Beginning with Shorewall 4.3.5, Shorewall-perl is an integral part + of Shorewall and support for Shorewall-shell has been discontinued.
@@ -555,112 +561,14 @@ DNAT- net 192.168.1.3 tcp 21 Dependence on Perl - Shorewall-perl is dependent on Perl (see the next section) which - has a large disk footprint. This makes Shorewall-perl less desirable in - an embedded environment. The best way to work around this limitation is - to install Shorewall-perl on an administrative system and employ - Shorewall-lite on your embedded systems. + Shorewall-perl is dependent on Perl which has a large disk + footprint. This makes Shorewall-perl less desirable in an embedded + environment. The best way to work around this limitation is to install + Shorewall-perl on an administrative system and employ Shorewall-lite on + your embedded systems.
-
- Shorewall-perl - Prerequisites - - - - Perl (I use Perl 5.8.8 but other 5.8 or later versions should - work fine) - - - If you want to be able to use DNS names in your Shorewall6 - configuration files, then Perl 5.10 is required together with the - Perl Socket6 module. - - - - - Perl Cwd Module - - - - Perl File::Basename Module - - - - Perl File::Temp Module - - - - Perl Getopt::Long Module - - - - Perl Carp Module - - - - Perl FindBin Module (Shorewall 4.0.3 and later) - - - - Perl Scalar::Util Module (Shorewall 4.0.6 and later) - - -
- -
- Shorewall-perl - Installation - - Either - - tar -jxf shorewall-perl-4.0.x.tar.bz2 -cd shorewall-perl-4.0.x -./install.sh - - or - - rpm -ivh shorewall-perl-4.0.x.noarch.rpm -
- -
- Using Shorewall-perl - - If you only install one compiler, then that compiler will be - used. - - If you install both compilers, then the compiler actually used - depends on the SHOREWALL_COMPILER setting in - shorewall.conf. The value of this option can be - either 'perl' or 'shell'. - - If you add 'SHOREWALL_COMPILER=perl' to - /etc/shorewall/shorewall.conf then by default, the - new compiler will be used on the system. If you add it to - shorewall.conf in a separate directory (such as a - Shorewall-lite export directory) then the new compiler will only be used - when you compile from that directory. - - If you only install one compiler, it is suggested that you do not - set SHOREWALL_COMPILER. - - You may also select the compiler to use on the command line using - the 'C option: - '-C shell' means use the shell compiler - - '-C perl' means use the perl compiler - The -C option overrides the setting in - shorewall.conf. - - Example:shorewall restart -C perl - - When the Shorewall-perl compiler has been selected, the - params file is processed twice, the second time using - the option which causes all variables set within the - file to be exported automatically by the shell. The Shorewall-perl - compiler uses the current environmental variables to perform variable - expansion within the other Shorewall configuration files. -
-
The Shorewall Perl Modules diff --git a/docs/Shorewall_and_Aliased_Interfaces.xml b/docs/Shorewall_and_Aliased_Interfaces.xml index afd067a71..0f8d66ce6 100644 --- a/docs/Shorewall_and_Aliased_Interfaces.xml +++ b/docs/Shorewall_and_Aliased_Interfaces.xml @@ -18,7 +18,7 @@ - 2001-2007 + 2001-2009 Thomas M. Eastep @@ -35,9 +35,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. @@ -198,11 +198,10 @@ eth0 eth1 206.124.146.178 connections using those addresses may be severed. - Beginning with Shorewall 1.3.14, Shorewall can actually create the - label (virtual interface) so that you can see the created - address using ifconfig. In addition to setting ADD_SNAT_ALIASES=Yes, you - specify the virtual interface name in the INTERFACE column as - follows. + Shorewall can create the label (virtual interface) + so that you can see the created address using ifconfig. In addition to + setting ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in + the INTERFACE column as follows. /etc/shorewall/masq#INTERFACE SUBNET ADDRESS eth0:0 eth1 206.124.146.178 @@ -243,11 +242,10 @@ eth0:2 = 206.124.146.180 connections using those addresses may be severed. - Beginning with Shorewall 1.3.14, Shorewall can actually create the - label (virtual interface) so that you can see the created - address using ifconfig. In addition to setting ADD_IP_ALIASES=Yes, you - specify the virtual interface name in the INTERFACE column as - follows. + Shorewall can create the label (virtual interface) + so that you can see the created address using ifconfig. In addition to + setting ADD_IP_ALIASES=Yes, you specify the virtual interface name in + the INTERFACE column as follows. /etc/shorewall/nat#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 206.124.146.178 eth0:0 192.168.1.3 no no @@ -284,8 +282,6 @@ ACCEPT net loc:192.168.1.3 tcp 22 eth1:0 is 192.168.20.254. You simply want your firewall to route between these two subnetworks. - This example applies to Shorewall 1.4.2 and later. - In /etc/shorewall/zones: #ZONE TYPE OPTIONS diff --git a/docs/UPnP.xml b/docs/UPnP.xml index cc1111ca6..1170fa48c 100644 --- a/docs/UPnP.xml +++ b/docs/UPnP.xml @@ -37,8 +37,8 @@
UPnP - In Shorewall 2.2.4, support was added for UPnP (Universal Plug and - Play) using linux-igd (Shorewall includes support for UPnP (Universal Plug and Play) using + linux-igd (http://linux-igd.sourceforge.net). UPnP is required by a number of popular applications including MSN IM. diff --git a/docs/blacklisting_support.xml b/docs/blacklisting_support.xml index c4eeb3d10..6973f56cd 100644 --- a/docs/blacklisting_support.xml +++ b/docs/blacklisting_support.xml @@ -43,9 +43,9 @@ - BLACKLISTNEWONLY=No -- All incoming packets are checked - against the blacklist. New blacklist entries can be used to terminate - existing connections. + BLACKLISTNEWONLY=No -- All incoming packets are checked against + the blacklist. New blacklist entries can be used to terminate existing + connections. @@ -189,12 +189,7 @@ ipset -B Blacklist 206.124.146.177 -b SMTP show dynamic - displays the dynamic blacklisting configuration. - - If you are running Shorewall 3.2.0 Beta2 or later, there are two - additional commands: - - logdrop <ip address list> - causes packets from the listed IP addresses to be dropped and logged by the diff --git a/docs/bridge-Shorewall-perl.xml b/docs/bridge-Shorewall-perl.xml index c7698a59d..5db909c4d 100644 --- a/docs/bridge-Shorewall-perl.xml +++ b/docs/bridge-Shorewall-perl.xml @@ -20,6 +20,8 @@ 2007 + 2009 + Thomas M. Eastep @@ -35,10 +37,8 @@ - This article applies to Shorewall-perl 4.0 and - later. If you are running a version of Shorewall earlier than Shorewall - 4.0.0-Beta4 or you are not running Shorewall-perl then please see this article. + This article applies to Shorewall-perl 4.3 and + later.
diff --git a/docs/configuration_file_basics.xml b/docs/configuration_file_basics.xml index 860beb686..02c3358ee 100644 --- a/docs/configuration_file_basics.xml +++ b/docs/configuration_file_basics.xml @@ -35,10 +35,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that - release. + 4.3.5then please see the documentation for that release. @@ -183,17 +182,16 @@ - /etc/shorewall/route_rules (Added in - Shorewall 3.2.0) - Defines routing rules to be used in conjunction - with the routing tables defined in - /etc/shorewall/providers. + /etc/shorewall/route_rules - Defines + routing rules to be used in conjunction with the routing tables + defined in /etc/shorewall/providers. /etc/shorewall/tcdevices, /etc/shorewall/tcclasses, - /etc/shorewall/tcfilters (tcfilters added in - Shorewall 4.2.0) - Define traffic shaping. + /etc/shorewall/tcfilters - Define traffic + shaping. @@ -202,9 +200,8 @@ - /etc/shorewall/vardir - (Added in - Shorewall 4.0.0-RC2) - Determines the directory where Shorewall - maintains its state. + /etc/shorewall/vardir - Determines the + directory where Shorewall maintains its state. @@ -236,9 +233,9 @@
Man Pages - Beginning with Shorewall version 3.4, man pages are provided in - section 5 for each of the Shorewall configuration files. The name of the - page is formed by prefixing the file name with "shorewall-". + Man pages are provided in section 5 for each of the Shorewall + configuration files. The name of the page is formed by prefixing the file + name with "shorewall-". Example — To view the manual page for /etc/shorewall/interfaces: @@ -270,10 +267,10 @@ ACCEPT net $FW tcp www #This is an end-of-line comment Attach Comment to Netfilter Rules - Beginning with Shorewall version 3.3.3, if you kernel and iptables - contain comment match support (see the output of shorewall show - capabilities), then you can attach comments to Netfilter rules. - This feature is available in the following files: + If you kernel and iptables contain comment match support (see the + output of shorewall show capabilities), then you can + attach comments to Netfilter rules. This feature is available in the + following files: @@ -298,9 +295,7 @@ ACCEPT net $FW tcp www #This is an end-of-line comment - Macro definition files (/etc/shorewall/macro.*) — Added in - Shorewall-perl 4.2.0. They are ignored by Shorewall-shell 4.1 and - later. + Macro definition files (/etc/shorewall/macro.*) @@ -330,7 +325,7 @@ COMMENT /sbin/shorewall-lite: gateway:~ # shorewall-lite show loc2net -Shorewall Lite 3.3.3 Chains loc2net at gateway - Mon Oct 16 15:04:52 PDT 2006 +Shorewall Lite 4.3.3 Chains loc2net at gateway - Mon Oct 16 15:04:52 PDT 2008 Counters reset Mon Oct 16 14:52:17 PDT 2006 @@ -411,16 +406,16 @@ smtp,www,pop3,imap #Services running on the firewall If you are using Shorewall Lite and are - running a version of Shorewall earlier than 3.2.9, it is not advisable - to use INCLUDE in the params file in an export - directory. If you do that, you must ensure that the included file is - also present on the firewall system's Shorewall Lite , it is not + advisable to use INCLUDE in the params file in an + export directory. If you do that, you must ensure that the included file + is also present on the firewall system's /etc/shorewall-lite/ directory. - Beginning with Shorewall version 3.2.9 (3.4.0 RC2), you can set - EXPORTPARAMS=No in shorewall.conf. That prevents - the params file from being copied into the compiled + If you only need the params file at compile + time, you can set EXPORTPARAMS=No in + shorewall.conf. That prevents the + params file from being copied into the compiled script. With EXPORTPARAMS=No, it is perfectly okay to use INCLUDE in the params file. @@ -470,9 +465,8 @@ smtp,www,pop3,imap #Services running on the firewall    ----- end rules ----- - Users of Shorewall-perl 4.0.6 and later may include multiple files - in one command using an embedded shell - command. + You may include multiple files in one command using an embedded shell command. Example (include all of the files ending in ".rules" in a directory:):gateway:/etc/shorewall # ls rules.d @@ -516,9 +510,9 @@ SHELL cat /etc/shorewall/rules.d/*.rules Variables may be used anywhere in the other configuration files. - Shorewall-perl users: If you use "$FW" on the right side of - assignments in the /etc/shorewall/params file, - you must also set the FW variable in that file. + If you use "$FW" on the right side of assignments in the + /etc/shorewall/params file, you must also set the + FW variable in that file. Example:/etc/shorewall/zones: @@ -587,35 +581,22 @@ SHELL cat /etc/shorewall/rules.d/*.rules - When expanding a variable, the acceptable forms of expansion depend - on whether you are using Shorewall-shell or Shorewall-perl. - - - - Shorewall-shell and all Shorewall versions prior to 4.0 can use - any form of expansion supported by the shell ($VAR, ${VAR}, - ${VAR:=val}, ...). - - - - Shorewall-perl only supports the $VAR and ${VAR} forms. - - + + Only the $VAR and ${VAR} forms of variable expansion are + supported. You may not use the more exotic forms supported by the shell + ($VAR, ${VAR}, ${VAR:=val}, ...) +
Embedded Shell and Perl - This feature was added in Shorewall-perl 4.0.6. To use it, you must - be running 4.0.6 or later and must be using Shorewall-perl - (SHOREWALL_COMPILER=perl in shorewall.conf). - Earlier versions of Shorewall offered extension scripts to allow users to extend Shorewall's functionality. Extension scripts were designed - to work under the limitations of the Bourne Shell. With Shorewall-perl, - Embedded scripts offer a richer and more flexible - extension capability. + to work under the limitations of the Bourne Shell. With the current + Perl-based compiler, Embedded scripts offer a + richer and more flexible extension capability. While inline scripts scripts may be written in either Shell or Perl, those written in Perl have a lot more power. @@ -654,7 +635,7 @@ ACCEPT dmz fw tcp 22 package Shorewall::User; use Shorewall::Config qw/shorewall/; - As part of the change that added embedded scripts: + A couple of more points should be mentioned: @@ -663,16 +644,17 @@ use Shorewall::Config qw/shorewall/; - A compile extension script was - added for use by Shorewall-perl. That script is run early in the - compilation process and allows users to load additional modules and to - define data and functions for use in subsequent embedded scripts and - extension scripts. + A compile extension script is + supported. That script is run early in the compilation process and + allows users to load additional modules and to define data and + functions for use in subsequent embedded scripts and extension + scripts. - A Manual Chain facility - was added. + Manual Chains may be + added in the compile extension + script.. @@ -866,8 +848,7 @@ POP/ACCEPT loc net:pop.gmail.com
Exclusion Lists - Shorewall 3.0 differs from earlier versions in that in most contexts - where a comma-separated list of addresses is accepted, an + Where a comma-separated list of addresses is accepted, an exclusion list may also be included. An exclusion list is a comma-separated list of addresses that begins with "!". @@ -922,30 +903,13 @@ Shorewall has detected the following iptables/netfilter capabilities: /etc/protocols. Similarly, when giving a port number you can use either an integer or a service name from /etc/services. - Shorewall-perl translates protocol names to protocol numbers and - service names to port numbers itself. - - In Shorewall versions 4.0.0 - 4.0.4, the mapping that it uses is - contained in the Perl module - /usr/share/shorewall-perl/Shorewall/Ports.pm. - That module is built when Shorewall is installed or upgraded using the - current /etc/protocols and - /etc/services files as input (if the build - program fails, a fallback version of the module is installed). - - To generate a new Ports.pm module:cp /usr/share/shorewall-perl/Shorewall/Ports.pm /usr/share/shorewall-perl/Shorewall/Ports.pm.backup -/usr/share/shorewall/buildports.pm > /usr/share/shorewall-perl/Shorewall/Ports.pm - - Beginning with Shorewall version 4.0.5, the - /usr/share/shorewall-perl/Shorewall/Ports.pm has - been eliminated and the Shorewall-perl compiler uses Perl's interfaces - to getprotobyname(3posix) and getservbyname(3posix). + The rules compiler translates protocol names to protocol numbers + and service names to port numbers itself. Also, unless otherwise documented, a protocol number/name can be - preceded by '!' to specify "All protocols except this one" (e.g., "!tcp"). - Shorewall-perl support for that feature was added in Shorewall - 4.2.6. + preceded by '!' to specify "All protocols except this one" (e.g., + "!tcp").
@@ -964,8 +928,7 @@ DNAT net loc:192.168.1.3 tcp 4000:4100 Also, unless otherwise documented, a port range can be preceded by '!' to specify "All ports except those in this range" (e.g., - "!4000:4100"). Shorewall-perl support for that feature was added in - Shorewall 4.2.6. + "!4000:4100").
@@ -995,18 +958,8 @@ DNAT net loc:192.168.1.3 tcp 4000:4100 - - Shorewall-perl requires multiport - match in order to accept port lists in Shorewall configuration files. It - further requires Extended multiport - match in order to accept port ranges in port lists. Shorewall-perl - versions earlier than 4.0.5 will never break a list longer than 15 ports - (with each range counting as two ports) into smaller lists. - - Also, unless otherwise documented, a port list can be preceded by - '!' to specify "All ports except these" (e.g., "!80,443"). Shorewall-perl - support for that feature was added in Shorewall 4.2.6. + '!' to specify "All ports except these" (e.g., "!80,443").
diff --git a/docs/fallback.xml b/docs/fallback.xml index b2bdd8769..aa7e42e78 100644 --- a/docs/fallback.xml +++ b/docs/fallback.xml @@ -18,7 +18,7 @@ - 2001-2005 + 2001-2009 Thomas M. Eastep @@ -44,22 +44,13 @@ cd to the distribution directory for the version of Shoreline - Firewall that you are currently running (NOT the version that you want - to fall back to). + Firewall that you want to fall back to. - Type ./fallback.sh + Type ./install.sh - - - The fallback script will replace /etc/shorewall[-lite]/*, - /var/lib/shorewall[-lite]/*, /etc/init.d/shorewall[-lilte]] (or - equivalent), and /sbin/shorewall[-lite] with the version of these files - from before the current version was installed. Any changes to any of - these files made since the installation will be lost. -
@@ -91,26 +82,4 @@ If you installed using an rpm, at a root shell prompt type rpm -e shorewall.
- -
- Shorewall-shell and Shorewall-perl - - Shorewall-shell and Shorewall-perl have no configuration files and - all of their released files are installed in a single directory. To - fallback to a prior release of one of these products using the tarballs, - simple re-install the older version. - - To uninstall these products when they have been installed using the - tarballs: - - - - rm -rf /usr/share/shorewall-shell - - - - rm -rf /usr/share/shorewall-perl - - -
diff --git a/docs/ipsets.xml b/docs/ipsets.xml index 51b013356..8817f3685 100644 --- a/docs/ipsets.xml +++ b/docs/ipsets.xml @@ -78,7 +78,7 @@ Example: "+Mirrors" - When using Shorewall-perl, the names of ipsets are restricted as + When using Shorewall, the names of ipsets are restricted as follows: @@ -130,76 +130,21 @@ /etc/shorewall/rules#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT +sshok $FW tcp 22 - If you are running Shorewall-shell: + Shorewall is not in the ipset load/reload business because the + Netfilter rule set is never cleared. That means that there is no + opportunity for Shorewall to load/reload your ipsets since that cannot be + done while there are any current rules using ipsets. -
- Shorewall can automatically manage the contents of your ipsets for - you. If you specify SAVE_IPSETS=Yes in /etc/shorewall/shorewall.conf - then "shorewall save" will save the contents of your ipsets. The file - where the sets are saved is formed by taking the name where the - Shorewall configuration is stored and appending "-ipsets". So if you - enter the command "shorewall save standard" then Shorewall will save the - file as /var/lib/shorewall/standard-ipsets + So: - Regardless of the setting of SAVE_IPSETS, the shorewall - -f start and shorewall restore commands - will restore the ipset contents corresponding to the Shorewall - configuration restored provided that the saved Shorewall configuration - specified exists. + + + Your ipsets must be loaded before Shorewall starts. You are free + to try to do that with the following code in + /etc/shorewall/init (it works for me; your mileage may + vary): - For example, shorewall restore standard would - restore the ipset contents from - /var/lib/shorewall/standard-ipsets provided that - /var/lib/shorewall/standard exists and is - executable and that - /var/lib/shorewall/standard-ipsets exists and is - executable. - - Also regardless of the setting of SAVE_IPSETS, the - shorewall forget command will purge the saved ipset - information (if any) associated with the saved shorewall configuration - being removed. - - You can also associate ipset contents with Shorewall configuration - directories using the following command: - - ipset -S > <config directory>/ipsets - - Example: - - ipset -S > /etc/shorewall/ipsets - - When you start or restart Shorewall (including using the - try command) from the configuration directory, your - ipsets will be configured from the saved ipsets file. Once again, this - behavior is independent of the setting of SAVE_IPSETS. - - As mentioned above, ipsets are well suited for large blacklists. - You can maintain your blacklist using the 'ipset' utility without ever - having to restart or refresh Shorewall. If you use the SAVE_IPSETS=Yes - feature just be sure to "shorewall save" after altering the blacklist - ipset(s). -
- - If you are running Shorewall-perl: - -
- Shorewall is now out of the ipset load/reload business. With - scripts generated by the Perl-based Compiler, the Netfilter rule set is - never cleared. That means that there is no opportunity for Shorewall to - load/reload your ipsets since that cannot be done while there are any - current rules using ipsets. - - So: - - - - Your ipsets must be loaded before Shorewall starts. You are - free to try to do that with the following code in - /etc/shorewall/init (it works for me; your mileage may - vary): - - if [ "$COMMAND" = start ]; then + if [ "$COMMAND" = start ]; then ipset -U :all: :all: ipset -U :all: :default: ipset -F @@ -207,32 +152,30 @@ ACCEPT +sshok $FW tcp 22 ipset -R < /etc/shorewall/ipsets fi - The file /etc/shorewall/ipsets will - normally be produced using the ipset -S - command. + The file /etc/shorewall/ipsets will + normally be produced using the ipset -S + command. - The above will work most of the time but will fail in a - shorewall stop - shorewall - start sequence if you use ipsets in your routestopped file - (see below). - + The above will work most of the time but will fail in a + shorewall stop - shorewall start + sequence if you use ipsets in your routestopped file (see + below). + - - Your ipsets may not be reloaded until Shorewall is stopped or - cleared. - + + Your ipsets may not be reloaded until Shorewall is stopped or + cleared. + - - If you specify ipsets in your routestopped file then Shorewall - must be cleared in order to reload your ipsets. - - + + If you specify ipsets in your routestopped file then Shorewall + must be cleared in order to reload your ipsets. + + - As a consequence, scripts generated by the Perl-based compiler - will ignore /etc/shorewall/ipsets and will issue a - warning if you set SAVE_IPSETS=Yes in - shorewall.conf. -
+ As a consequence, scripts generated by the Perl-based compiler will + ignore /etc/shorewall/ipsets and will issue a warning + if you set SAVE_IPSETS=Yes in shorewall.conf Example (Note -- this example is applicable to ipset versions up to and including 2.4. In 2.5, the binding feature of ipsets is scheduled for diff --git a/docs/shorewall_extension_scripts.xml b/docs/shorewall_extension_scripts.xml index 0948f0b61..5c32c6341 100644 --- a/docs/shorewall_extension_scripts.xml +++ b/docs/shorewall_extension_scripts.xml @@ -35,9 +35,10 @@ - This article applies to Shorewall 4.0 and later. If you are running - a version of Shorewall earlier than Shorewall 4.0.0 then please see the - documentation for that release. + This article applies to Shorewall 4.3 and + later. If you are running a version of Shorewall earlier than Shorewall + 4.3.5 then please see the documentation for that + release.
@@ -69,9 +70,8 @@ - compile -- (Added in Shorewall-perl version - 4.0.6). Invoked by the Shorewall-perl compiler early in the - compilation process. Must be written in Perl. + compile -- Invoked by the rules compiler + early in the compilation process. Must be written in Perl. @@ -87,14 +87,12 @@ start -- invoked after the firewall has - been started or restarted. The script is also invoked by - Shorewall-shell after a successful 'restore'. + been started or restarted. started -- invoked after the firewall has - been marked as 'running'. The script is also invoked by - Shorewall-shell after a successful 'restore'. + been marked as 'running'. @@ -147,11 +145,11 @@ - isusable -- (Added in Shorewall-perl - version 4.0.3) invoked when Shorewall is trying to determine the - usability of the network interface associated with an optional entry - in /etc/shorewall/providers. $1 is the name of - the interface which will have been determined to be up and configured + isusable -- invoked when Shorewall is + trying to determine the usability of the network interface associated + with an optional entry in + /etc/shorewall/providers. $1 is the name of the + interface which will have been determined to be up and configured before the script is invoked. The return value from the script indicates whether or not the interface is usable (0 = usable, other = unusable). @@ -185,16 +183,14 @@ esac - save -- (Added in Shorewall version 4.2.0 - Beta2). This script is invoked during execution of the - shorewall save and shorewall-lite - save commands. + save -- This script is invoked during + execution of the shorewall save and + shorewall-lite save commands. - restored -- (Added in Shorewall-perl - version 4.2.6). This script is invoked at the completion of a - successful shorewall restore and + restored -- This script is invoked at the + completion of a successful shorewall restore and shorewall-lite restore. @@ -210,29 +206,23 @@ esac scripts. - + script - Shorewall-shell - - Shorewall-perl + Commands clear clear - - clear compile - - - check, compile, export, load, refresh, reload, restart, restore,start @@ -240,24 +230,18 @@ esac continue - load, refresh, reload, restart, restore, start - init - load, refresh, reload, restart, restore, start - load, refresh, reload, restart restore, start initdone - refresh, restart, restore, start - check, compile, export, refresh, restart, start @@ -265,15 +249,11 @@ esac isusable refresh, restart, restore, start - - refresh, restart, restore, start maclog - load, refresh, reload, restart, restore, start - check, compile, export, refresh, restart, start @@ -281,23 +261,17 @@ esac refresh refresh - - refresh refreshed refresh - - refresh restored - - - restore @@ -305,23 +279,17 @@ esac save save - - save start - load, reload, restart, restore, start - load, reload, restart, start started - load, reload, restart, restore, start - load, reload, restart, start @@ -329,24 +297,18 @@ esac stop stop, clear - - stop, clear stopped stop, clear - - stop, clear tcclear load, reload, restart, restore, start - - load, reload, restart, restore, start @@ -362,12 +324,10 @@ esac run_iptables will run the iptables utility passing the arguments to run_iptables and if the command fails, the firewall will be stopped (or restored from the last - save command, if any). Note that when - Shorewall-shell invokes this script during restore, - The run_iptables function does nothing; calls to - that function are effectively ignored. run_iptables - should not be called from the started or - restored scripts. + save command, if any). + run_iptables should not be called from the + started or restored + scripts. @@ -428,99 +388,38 @@ esac -
- Shorewall-shell - - When compiling your firewall configuration, Shorewall copies most - extension scripts directly into the "compiled" program where they are - executed in-line during processing of the start, restart and restore - commands. When copying a script, Shorewall indents the script to match - the surrounding code; if you have 'awk' installed on the system where - the configuration is being compiled, Shorewall can correctly handle line - continuation in your script ("\" as the last character on a line). If - you do not have awk, you may not use line continuation in your scripts. - Also beware that quoted strings continued from one line to another will - have extra whitespace inserted as a result of indentation. - - - The /etc/shorewall/params script is - processed only during compilation if EXPORTPARAMS=No in - shorewall.conf. So shell variables set in that - file may be used in Shorewall configuration files only. Any variables - that your extension scripts require at run-time on the firewall system - should be set in the init extension script (if - you need variable values in the stop or - stopped scripts, you will need to set their value - in stop since init is not - invoked when processing the stop and - clear commands). - - When EXPORTPARAMS=Yes (the default), the - /etc/shorewall/params script is processed during - compilation and copied into the - compiled script as described above. So shell variables set during - compilation may be used in Shorewall configuration files while those - set at run-time are available to your other extension scripts.Note - that if you assign dynamic values to variables, there is no guarantee - that the value calculated at compile time will be the same as what is - calculated at run time. This is particularly true if you use the - shorewall compile command to compile a program then - run that program at a later time or if you use Shorewall Lite. - - - - Extension scripts associated with a particular chain or action - are not copied into the compiled script; they are rather processed - directly by the compiler using the Bourne shell "." command. For - example, if A is an action then if /etc/shorewall/A exists then it will be - processed by the compiler rather than copied into the compiled - script. - -
-
- Shorewall-perl + Compile-time vs Run-time Scripts - Because the compiler is written in Perl, some of your extension - scripts from earlier versions will no longer work because Shorewall-perl - runs those extension scripts at compile-time rather than at - run-time. + Shorewall runs some extension scripts at compile-time rather than + at run-time. The following table summarizes when the various extension scripts are run: - + Compile-time Run-time - - Eliminated compile clear - - continue initdone init - - maclog isusable - - @@ -528,32 +427,24 @@ esac actions) start - - started - - stop - - stopped - - @@ -588,8 +479,7 @@ esac script returns a 'true' value; otherwise, the compiler will assume that the script failed and will abort the compilation. - Beginning with Shorewall version 4.0.6, each compile-time script - is implicitly prefaced with: + Each compile-time script is implicitly prefaced with: package Shorewall::User; @@ -597,7 +487,7 @@ esac line:use Shorewall::Chains;For more complex scripts, you may need to 'use' other Shorewall Perl modules -- browse /usr/share/shorewall-perl/Shorewall/ to see + class="directory">/usr/share/shorewall/Shorewall/ to see what's available. When a script is invoked, the name>" Example:add_rule( $chainref, '-j ACCEPT' ); - Beginning with Shorewall 4.0.5, add_rule() accepts an optional - third argument; If that argument evaluates to true and the passed rule - contains a --dports list with more than - 15 ports (a port range counts as two ports), the rule will be split into - multiple rules where each resulting rule has 15 or fewer ports in its - --dports list. + The add_rule() function accepts an optional third argument; If + that argument evaluates to true and the passed rule contains a --dports list with more than 15 ports (a port + range counts as two ports), the rule will be split into multiple rules + where each resulting rule has 15 or fewer ports in its --dports list. To insert a rule into the chain: insert_rule( $chainref, <rulenum>, <the rule> );The log_rule_limit() function works like it @@ -662,12 +552,6 @@ esac Example: my $chainref = $filter_table->{INPUT}; #Same as above with a few less keystrokes; runs faster too - - The 'continue' script has been eliminated because it no longer - make any sense under Shorewall-perl. That script was designed to allow - you to add special temporary rules during [re]start. Shorewall-perl - doesn't need such rules since the rule set is instantiated atomically by - table.
diff --git a/docs/shorewall_logging.xml b/docs/shorewall_logging.xml index 56be5808e..73ea0adc9 100644 --- a/docs/shorewall_logging.xml +++ b/docs/shorewall_logging.xml @@ -18,7 +18,7 @@ - 2001 - 2007 + 2001 - 2009 Thomas M. Eastep @@ -35,9 +35,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. @@ -184,13 +184,12 @@ - Beginning with Shorewall version 1.3.12, if your kernel has ULOG - target support (and most vendor-supplied kernels do), you may also - specify a log level of ULOG (must be all caps). When ULOG is used, - Shorewall will direct Netfilter to log the related messages via the ULOG - target which will send them to a process called ulogd. - The ulogd program is included in most distributions and is also - available from If your kernel has ULOG target support (and most vendor-supplied + kernels do), you may also specify a log level of ULOG (must be all + caps). When ULOG is used, Shorewall will direct Netfilter to log the + related messages via the ULOG target which will send them to a process + called ulogd. The ulogd program is included in most + distributions and is also available from http://www.netfilter.org/projects/ulogd/index.html. Ulogd can be configured to log all Shorewall messages to their own log file. @@ -233,12 +232,8 @@ gateway:/etc/shorewall# logwatch and dump commands. - Beginning in Shorewall-perl 4.1, the NFLOG target is - supported. - - NFLOG is a successor to ULOG. When using Shorewall-perl 4.1 or later, both ULOG - and NFLOG may be followed by a list of up to three numbers in + The NFLOG target, a successor to ULOG, is supported shorewall. + Both ULOG and NFLOG may be followed by a list of up to three numbers in parentheses. diff --git a/docs/shorewall_prerequisites.xml b/docs/shorewall_prerequisites.xml index 6e9e55722..7149a2e0b 100644 --- a/docs/shorewall_prerequisites.xml +++ b/docs/shorewall_prerequisites.xml @@ -33,9 +33,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. @@ -90,17 +90,47 @@ The firewall monitoring display is greatly improved if you have awk (gawk) installed. + + + On the system where the Shorewall package itself is installed, + you must have Perl installed (preferably Perl 5.8.10): + + + + If you want to be able to use DNS names in your Shorewall6 + configuration files, then Perl 5.10 is required together with the + Perl Socket6 module. + + + + Perl Cwd Module + + + + Perl File::Basename Module + + + + Perl File::Temp Module + + + + Perl Getopt::Long Module + + + + Perl Carp Module + + + + Perl FindBin Module + + + + Perl Scalar::Util Module + + +
- -
- Shorewall-perl Requirements - - Shorewall-perl is a - re-implementation of the Shorewall configuration compiler written in Perl. - It is much faster than the classic Shorewall-shell compiler and produces a - firewall script that runs much faster. It's prerequisites are described in - the Shorewall-perl - article. -
diff --git a/docs/starting_and_stopping_shorewall.xml b/docs/starting_and_stopping_shorewall.xml index efbe15a72..7b83eaddf 100644 --- a/docs/starting_and_stopping_shorewall.xml +++ b/docs/starting_and_stopping_shorewall.xml @@ -41,9 +41,9 @@ - This article applies to Shorewall 3.0 and + This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall - 3.0.0 then please see the documentation for that + 4.3.5 then please see the documentation for that release. @@ -133,12 +133,12 @@ executed. - Beginning with Shorewall 3.1, shorewall - start is implemented as a compile and - go; that is, the configuration is compiled and if there - are no compilation errors then the resulting compiled script is - executed. If there are compilation errors, the command is aborted - and the state of the firewall is not altered. + shorewall start is implemented as a + compile and go; that is, the configuration is + compiled and if there are no compilation errors then the resulting + compiled script is executed. If there are compilation errors, the + command is aborted and the state of the firewall is not + altered. @@ -207,15 +207,14 @@ To trace the execution of shorewall start and write the trace to the file /tmp/trace, you would enter:shorewall trace start 2> /tmp/trace - If you are running Shorewall-perl, the trace keyword does not result in a trace of - the execution of the Shorewall-perl compiler. It rather causes - additional diagnostic information to be included in warning and - error messages generated by the compiler. + The trace keyword does not + result in a trace of the execution of the Shorewall rules compiler. + It rather causes additional diagnostic information to be included in + warning and error messages generated by the compiler. - Beginning with Shorewall 4.0.5, you may also include the word - debug as the first argument to the + You may also include the word debug as the first argument to the /sbin/shorewall and /sbin/shorewall-lite commands.shorewall debug restartIn most cases, debug is a synonym for @@ -346,17 +345,12 @@ running iptables dozens or even hundreds of times. - Under Shorewall versions < 4.0.0, - /etc/init.d/shorewall - (/etc/rc.d/rc.firewall) uses the -f option when - it is processing a request to start Shorewall. Beginning with - Shorewall 4.0.0, the default is to not use -f. If you wish to change - the default, you must set the OPTIONS shell variable in either + The default is to not use -f. If you wish to change the default, + you must set the OPTIONS shell variable in either /etc/default/shorewall or /etc/sysconfig/shorewall (if your distribution provides neither of these files, you must create one or the other). - For example, to continue to use -f under Shorewall 4.0.0 and later, - you would have:OPTIONS="-f" + @@ -515,7 +509,7 @@
Commands - The general form of a command in Shorewall 4.0 is: + The general form of a command is:
shorewall [ <options> ] <command> [ diff --git a/docs/traffic_shaping.xml b/docs/traffic_shaping.xml index 39bbfda6b..5ffd237a0 100644 --- a/docs/traffic_shaping.xml +++ b/docs/traffic_shaping.xml @@ -134,65 +134,17 @@ classes (and their bandwidth limits), and it uses SFQ inside these classes to make sure, that different data streams are handled equally. - If you are running Shorewall-shell or if you - are running Shorewall-perl 4.1.5 or earlier:
- You can only shape outgoing traffic. The - reason for this is simple, the packets were already received by your - network card before you can decide what to do with them. So - the only choice would be to drop them which normally makes no sense - (since you received the packet already, it went through the possible - bottleneck (the incoming connection). The next possible bottleneck - might come if the packet leaves on another interface, so this will be - the place where queuing might occur. So, defining queues for incoming - packets is not very useful, you just want to have it forwarded to the - outgoing interface as fast as possible. + You can shape incoming traffic through use of an + Intermediate Frame Block (IFB) device. See below. But beware: using an + IFB can result in queues building up both at your ISPs router and at your + own. - There is one exception, though. Limiting incoming traffic to a - value a bit slower than your actual line speed will avoid queuing on - the other end of that connection. This is mostly useful if you don't - have access to traffic control on the other side and if this other - side has a faster network connection than you do (the line speed - between the systems is the bottleneck, e.g. a DSL or Cable Modem - connection to your provider's router, the router itself is normally - connected to a much faster backbone). So, if you drop packets that are - coming in too fast, the underlying protocol might recognize this and - slow down the connection. TCP has a builtin mechanism for this, UDP - has not (but the protocol over UDP might recognize it , if there is - any). - - The reason why queuing is bad in these cases is, that you might - have packets which need to be prioritized over others, e.g. VoIP or - ssh. For this type of connections it is important that packets arrive - in a certain amount of time. For others like HTTP downloads, it does - not really matter if it takes a few seconds more. - - If you have a large queue on the other side and the router there - does not care about QoS or the QoS bits are not set properly, your - important packets will go into the same queue as your less time - critical download packets which will result in a large delay. -
- - If you are running Shorewall-perl 4.1.6 or - later:
- You can shape incoming traffic through use of an - Intermediate Frame Block (IFB) device. See below. But beware: - using an IFB can result in queues building up both at your ISPs router - and at your own. -
- - This is not to say that you cannot shape - download traffic, regardless of which Shorewall release you are - running. - -
- If you wish to shape downloads, you can always configure traffic - shaping on your firewall's local interface. An example appears below. - - Again, however, this can result in queues - building up both at your ISPs router and at your own. -
+ If you wish to shape downloads, you can also configure traffic + shaping on your firewall's local interface. An example appears below. Again, however, this can result in queues building up both at your ISPs router + and at your own. You shape and control outgoing traffic by assigning the traffic to classes. Each class is associated with exactly one @@ -371,13 +323,10 @@ only once in this file. You may NOT specify the name of an alias (e.g., eth0:0) here; see FAQ #18. You man NOT specify wildcards here, e.g. if you have multiple ppp - interfaces, you need to put them all in here! With Shorewall - versions prior to 3.0.8 and 3.2.0 Beta 8, the device named in this - column must exist at the time that Shorewall is started, restarted - or refreshed. Beginning with Shorewall 3.0.8 and 3.2.0 Beta 8, - Shorewall will determine if the device exists and will only - configure the device if it does exist. If it doesn't exist, the - following warning is issued: + interfaces, you need to put them all in here! Shorewall will + determine if the device exists and will only configure the device if + it does exist. If it doesn't exist, the following warning is + issued: WARNING: Device <device name> not found -- traffic-shaping configuration skipped @@ -385,10 +334,9 @@ Shorewall assigns a sequential interface number to each interface (the first entry in /etc/shorewall/tcdevices is interface 1, the - second is interface 2 and so on) Beginning with Shorewall-perl - 4.1.6, you can explicitly specify the interface number by prefixing - the interface name with the number and a colon (":"). Example: - 1:eth0. + second is interface 2 and so on) You can also explicitly specify the + interface number by prefixing the interface name with the number and + a colon (":"). Example: 1:eth0. @@ -400,8 +348,8 @@ exceeded, the excess packets are dropped. You want this mainly if you have a DSL or Cable Connection to avoid queuing at your providers side. If you don't want any traffic to be dropped set this - to a value faster than your interface maximum rate (or to 0 (zero), - if you are running Shorewall 3.2.6 or later). + to a value faster than your interface maximum rate (or to 0 + (zero). To determine the optimum value for this setting, we recommend that you start by setting it significantly below your measured @@ -420,8 +368,8 @@ - OPTIONS (Added in Shorewall-perl 4.1.4) — A comma-separated - list of options from the following list: + OPTIONS — A comma-separated list of options from the following + list: @@ -439,14 +387,13 @@ - REDIRECTED INTERFACES (Added in Shorewall-perl 4.1.6) — - Entries are appropriate in this column only if the device in the - INTERFACE column names a Intermediate Frame - Block (IFB). It lists the physical interfaces that will have - their input shaped using classes defined on the IFB. Neither the IFB - nor any of the interfaces listed in this column may have an - IN-BANDWIDTH specified. You may specify zero (0) or a dash ("-:) in - the IN-BANDWIDTH column. + REDIRECTED INTERFACES — Entries are appropriate in this column + only if the device in the INTERFACE column names a Intermediate Frame Block (IFB). It lists the + physical interfaces that will have their input shaped using classes + defined on the IFB. Neither the IFB nor any of the interfaces listed + in this column may have an IN-BANDWIDTH specified. You may specify + zero (0) or a dash ("-:) in the IN-BANDWIDTH column. IFB devices automatically get the classify option. @@ -473,15 +420,14 @@ ppp0 6000kbit 500kbit - INTERFACE - Name of interface. Users of Shorewall-perl 4.1.6 - or later may also specify the interface number. Must match the name - (or number) of an interface with an entry in - /etc/shorewall/tcdevices. If the interface has - the classify option in - /etc/shorewall/tcdevices, then the interface - name or number must be followed by a colon and a class - number. Examples: eth0:1, 4:9. Class numbers must be - unique for a given interface. + INTERFACE - Name of interface. Users may also specify the + interface number. Must match the name (or number) of an interface + with an entry in /etc/shorewall/tcdevices. If + the interface has the classify + option in /etc/shorewall/tcdevices, then the + interface name or number must be followed by a colon and a + class number. Examples: eth0:1, 4:9. Class + numbers must be unique for a given interface. @@ -685,11 +631,10 @@ ppp0 6000kbit 500kbit - The "T" qualifier was added in Shorewall version 3.3.6 and - is not available in earlier versions. Use - this qualifier if you want the rule to apply equally to traffic - being routed through the firewall and to traffic originating on - the firewall itself. + Use the 'T' qualifier if you want the + rule to apply equally to traffic being routed through the firewall + and to traffic originating on the firewall + itself. Normally, the mark is applied to the packet. If you follow the @@ -735,12 +680,11 @@ ppp0 6000kbit 500kbit - COMMENT (Added in - Shorewall version 3.3.3) -- the rest of the line will be - attached as a comment to the Netfilter rule(s) generated by the - following entries. The comment will appear delimited by "/* ... - */" in the output of shorewall show - mangle + COMMENT -- the rest of + the line will be attached as a comment to the Netfilter rule(s) + generated by the following entries. The comment will appear + delimited by "/* ... */" in the output of shorewall + show mangle To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. @@ -767,9 +711,7 @@ ppp0 6000kbit 500kbit prio - With Shorewall versions prior to 3.2.3, classify rules are - always placed in the POSTROUTING chain. Beginning with Shorewall - 3.2.3, classification occurs in the POSTROUTING chain Classification occurs in the POSTROUTING chain except when the SOURCE contains $FW[:<address>] in which case, the classify action takes place in the OUTPUT chain. When used with the @@ -783,7 +725,7 @@ ppp0 6000kbit 500kbit - SOURCE - Source of the packet. + SOURCE - Source of the packet. May be: @@ -835,7 +777,7 @@ ppp0 6000kbit 500kbit - DEST - Destination of the packet. + DEST - Destination of the packet. May be: @@ -873,12 +815,8 @@ ppp0 6000kbit 500kbit ipp2p option without the leading "--" (example "bit" for bit-torrent). If no PORT is given, "ipp2p" is assumed. Note that the xtables-addons version of IPP2P does not support the "ipp2p" option; - to use that version of IPP2P with Shorewall-shell or with - Shorewall-perl 4.2.4 or earlier, you must specify an option other - than "ipp2p". Shorewall-perl 4.2.5 and later support a - comma-separated list of IPP2P options in this column; if the column - is empty or contains "ipp2p", then those versions of Shorewall-perl - will substitute "edk,kazaa,gnu,dc". + if the column is empty or contains "ipp2p" when using that version + of IPP2P, Shorewall will substitute "edk,kazaa,gnu,dc". This column is ignored if PROTOCOL = all but must be entered if any of the following field is supplied. In that case, it is @@ -893,11 +831,10 @@ ppp0 6000kbit 500kbit - USER/GROUP (Added in Shorewall version 1.4.10) - (Optional) - This column may only be non-empty if the SOURCE is the firewall - itself. When this column is non-empty, the rule applies only if the - program generating the output is running under the effective user - and/or group. It may contain : + USER/GROUP (Optional) This column may only be non-empty if the + SOURCE is the firewall itself. When this column is non-empty, the + rule applies only if the program generating the output is running + under the effective user and/or group. It may contain : [!][<user name or number>]:[<group name or number>][+<program name>] @@ -913,9 +850,9 @@ ppp0 6000kbit 500kbit - TEST - Defines a test on the existing packet or connection - mark. The rule will match only if the test returns true. Tests have - the format [!]<value>[/<mask>][:C] + TEST (Optional) Defines a test on the existing packet or + connection mark. The rule will match only if the test returns true. + Tests have the format [!]<value>[/<mask>][:C] Where: @@ -934,11 +871,10 @@ ppp0 6000kbit 500kbit - LENGTH (Optional, added in Shorewall version 3.2.0) Packet - Length - This field, if present, allows you to match the length of a - packet against a specific value or range of values. A range is - specified in the form <min>:<max> where either - <min> or <max> (but not both) may be omitted. If + LENGTH (Optional) This field, if present, allows you to match + the length of a packet against a specific value or range of values. + A range is specified in the form <min>:<max> where + either <min> or <max> (but not both) may be omitted. If <min> is omitted, then 0 is assumed; if <max> is omitted, than any packet that is <min> or longer will match. @@ -951,9 +887,8 @@ ppp0 6000kbit 500kbit - TOS (Optional, added in Shorewall version 3.2.0 Beta 6) Type - of Service. Either a standard name, or a numeric value to - match. + TOS (Optional) Type of Service. Either a standard name, or a + numeric value to match.
@@ -971,9 +906,8 @@ ppp0 6000kbit 500kbit - HELPER (Optional, added in Shorewall version 4.2.0 Beta 2). - Names one of the Netfilter protocol helper modules such as - ftp, sip, + HELPER (Optional). Names one of the Netfilter protocol helper + modules such as ftp, sip, amanda, etc. @@ -1063,8 +997,7 @@ SAVE 0.0.0.0/0 0.0.0.0/0 all - - - Mark all forwarded VOIP connections with connection mark 1 and ensure that all VOIP packets also receive that mark (assumes that - nf_conntrack_sip is loaded and that Shorewall-perl 4.2.0 or later is - being used). + nf_conntrack_sip is loaded). #MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST CONNBYTES TOS HELPER # PORT(S) GROUP @@ -1328,8 +1261,7 @@ eth0 4 94mbit full default #for local traff
Intermediate Frame Block (IFB) Devices - Beginning with Shorewall 4.1.6, Shorewall-perl includes support for - IFBs. The principles behind an IFB is fairly simple: + The principles behind an IFB is fairly simple: diff --git a/docs/troubleshoot.xml b/docs/troubleshoot.xml index bf1c673a8..94e37ee1d 100644 --- a/docs/troubleshoot.xml +++ b/docs/troubleshoot.xml @@ -36,25 +36,109 @@ <quote>shorewall start</quote> and <quote>shorewall restart</quote> Errors -
- Shorewall-shell + If the error is detected by the Shorewall compiler, it should be + fairly obvious where the problem was found. Each error message includes + the configuration file name and line number where the error was detected + and often gives the particular item in error. The item is either enclosed + in parentheses or is at the end following a colon (":"). - If you use the Shorewall-shell compiler and you receive an error - message when starting or restarting the firewall and you can't determine - the cause. First, if your VERBOSITY setting in shorewall.conf is less - than 2, then try running with a higher verbosity level by using the "-v" - option: + Example:gateway:~/test # shorewall restart . +Compiling... + ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) +gateway:~/test # In this case, line 19 in the rules file + specified an invalid ICMP Type (0/400). -
- shorewall -vv [re]start -
+ Additional information about the error can be obtained using the + 'debug' keyword:gateway:~/test # shorewall debug restart . +Compiling... + ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) at /usr/share/shorewall/Shorewall/Config.pm line 338 + Shorewall::Config::fatal_error('Invalid ICMP Type (0/400)') called at /usr/share/shorewall/Shorewall/Chains.pm line 885 + Shorewall::Chains::validate_icmp('0/400') called at /usr/share/shorewall/Shorewall/Chains.pm line 949 + Shorewall::Chains::do_proto('icmp', '0/400', '-') called at /usr/share/shorewall/Shorewall/Rules.pm line 1055 + Shorewall::Rules::process_rule1('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1290 + Shorewall::Rules::process_rule('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1336 + Shorewall::Rules::process_rules() called at /usr/share/shorewall/Shorewall/Compiler.pm line 799 + Shorewall::Compiler::compiler('/var/lib/shorewall/.restart', '/root/test', 0, 4) called at /usr/share/shorewall/compiler.pl line 86 +gateway:~/test # This information is useful to Shorewall + support if you need to file a problem + report. - That will give you additional progress messages that may make it - clear which entry in which file is generating the error. + The end of the compile phase is signaled by a message such as the + following:Shorewall configuration compiled to /var/lib/shorewall/.restartErrors + occurring past that point are said to occur at + run-time because they occur during the running of + the compiled firewall script (/var/lib/shorewall/.restart in the case of + the above message). - If that didn't help, then do the following: + One common run-time failure is that the iptables-restore program + encounters an error. This will produce an error such as the + following:... +Restarting Shorewall.... +iptables-restore v1.3.6: No chain/target/match by that name +Error occurred at line: 83 +Try `iptables-restore -h' or 'iptables-restore --help' for more information. + ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input +Restoring Shorewall... +Shorewall restored from /var/lib/shorewall/restore +Terminated +gateway:~/test # A look at /var/lib/shorewall/restore at line + 83 might show something like the following:-A reject -p tcp -j REJECT --reject-with tcp-resetIn + this case, the user had compiled his own kernel and had forgotten to + include REJECT target support (see kernel.htm). - + You may also include the word debug + as the first argument to the /sbin/shorewall and + /sbin/shorewall-lite commands.shorewall debug restartIn + most cases, debug is a synonym for + trace. The exceptions are: + + + + debug is ignored by the + Shorewall compiler. + + + + debug causes altered behavior + of generated scripts. These scripts normally use + iptables-restore to install the Netfilter ruleset but with + debug, the commands normally passed + to iptables-restore in its input file are passed + individually to iptables. This is a diagnostic aid + which allows identifying the individual command that is causing + iptables-restore to fail; it should be used when + iptables-restore fails when executing a COMMIT + command. + + + + + The debug feature is strictly for + problem analysis. When debug is + used: + + + + The firewall is made 'wide open' before the rules are + applied. + + + + The routestopped file is not + consulted. + + + + The rules are applied in the canonical + iptables-restore order. So if you need critical + hosts to be always available during start/restart, you may not be + able to use debug. + + + + + In other run-time failure cases: Make a note of the error message that you see. @@ -67,177 +151,15 @@ Look at the /tmp/trace file and see if that helps you determine what the problem is. Be sure you find the - place in the log where the error message you saw is generated -- If - you are using Shorewall 1.4.0 or later, you should find the message - near the end of the log. + place in the log where the error message you saw is generated -- you + should find the message near the end of the log. If you still can't determine what's wrong then see the support page. - - - - Startup Error - - During startup, a user sees the following: - - Adding Common Rules -iptables: No chain/target/match by that name -Terminated - - A search through the trace for No chain/target/match by - that name turned up the following: - - + echo 'Adding Common Rules' -+ add_common_rules -+ run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset -++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset -++ sed 's/!/! /g' -+ iptables -A reject -p tcp -j REJECT --reject-with tcp-reset -iptables: No chain/target/match by that name - - - The command that failed was: iptables -A reject - -p tcp -j REJECT --reject-with tcp-reset. In this - case, the user had compiled his own kernel and had forgotten to - include REJECT target support (see kernel.htm) - -
- -
- Shorewall-perl - - If the error is detected by the Shorewall-perl compiler, it should - be fairly obvious where the problem was found. Each error message - includes the configuration file name and line number where the error was - detected and often gives the particular item in error. The item is - either enclosed in parentheses or is at the end following a colon - (":"). - - Example:gateway:~/test # shorewall restart . -Compiling... - ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) -gateway:~/test # In this case, line 19 in the rules file - specified an invalid ICMP Type (0/400). - - Additional information about the error can be obtained using the - 'debug' keyword:gateway:~/test # shorewall debug restart . -Compiling... - ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) at /usr/share/shorewall-perl/Shorewall/Config.pm line 338 - Shorewall::Config::fatal_error('Invalid ICMP Type (0/400)') called at /usr/share/shorewall-perl/Shorewall/Chains.pm line 885 - Shorewall::Chains::validate_icmp('0/400') called at /usr/share/shorewall-perl/Shorewall/Chains.pm line 949 - Shorewall::Chains::do_proto('icmp', '0/400', '-') called at /usr/share/shorewall-perl/Shorewall/Rules.pm line 1055 - Shorewall::Rules::process_rule1('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall-perl/Shorewall/Rules.pm line 1290 - Shorewall::Rules::process_rule('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall-perl/Shorewall/Rules.pm line 1336 - Shorewall::Rules::process_rules() called at /usr/share/shorewall-perl/Shorewall/Compiler.pm line 799 - Shorewall::Compiler::compiler('/var/lib/shorewall/.restart', '/root/test', 0, 4) called at /usr/share/shorewall-perl/compiler.pl line 86 -gateway:~/test # This information is useful to Shorewall - support if you need to file a problem - report. - - The end of the compile phase is signaled by a message such as the - following:Shorewall configuration compiled to /var/lib/shorewall/.restartErrors - occurring past that point are said to occur at - run-time because they occur during the running of - the compiled firewall script (/var/lib/shorewall/.restart in the case of - the above message). - - One common run-time failure is that the iptables-restore program - encounters an error. This will produce an error such as the - following:... -Restarting Shorewall.... -iptables-restore v1.3.6: No chain/target/match by that name -Error occurred at line: 83 -Try `iptables-restore -h' or 'iptables-restore --help' for more information. - ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input -Restoring Shorewall... -Shorewall restored from /var/lib/shorewall/restore -Terminated -gateway:~/test # A look at /var/lib/shorewall/restore at line - 83 might show something like the following:-A reject -p tcp -j REJECT --reject-with tcp-resetIn - this case, the user had compiled his own kernel and had forgotten to - include REJECT target support (see kernel.htm). - - f you are running Shorewall-perl 4.0.5 or later, you may also - include the word debug as the first - argument to the /sbin/shorewall and - /sbin/shorewall-lite commands.shorewall debug restartIn - most cases, debug is a synonym for - trace. The exceptions are: - - - - debug is ignored by the - Shorewall-perl compiler. - - - - debug causes altered behavior - of scripts generated by the Shorewall-perl compiler. These scripts - normally use iptables-restore to install the - Netfilter ruleset but with debug, - the commands normally passed to iptables-restore - in its input file are passed individually to - iptables. This is a diagnostic aid which allows - identifying the individual command that is causing - iptables-restore to fail; it should be used when - iptables-restore fails when executing a COMMIT - command. - - - - - The debug feature is strictly - for problem analysis. When debug is - used: - - - - The firewall is made 'wide open' before the rules are - applied. - - - - The routestopped file is not - consulted. - - - - The rules are applied in the canonical - iptables-restore order. So if you need critical - hosts to be always available during start/restart, you may not be - able to use debug. - - - - - In other run-time failure cases: - - Make a note of the error message that you see. - - - - shorewall debug start 2> - /tmp/trace - - - - Look at the /tmp/trace file and see if - that helps you determine what the problem is. Be sure you find the - place in the log where the error message you saw is generated -- - you should find the message near the end of the log. - - - - If you still can't determine what's wrong then see the - support page. - - -
+
diff --git a/docs/upgrade_issues.xml b/docs/upgrade_issues.xml index eec372ceb..23251a102 100644 --- a/docs/upgrade_issues.xml +++ b/docs/upgrade_issues.xml @@ -29,6 +29,8 @@ 2008 + 2009 + Thomas M. Eastep @@ -71,12 +73,22 @@ command to see the groups associated with each of your zones.
+
+ Versions >= 4.3.5 + + If you are using Shorewall-perl, there are no additional upgrade + issues. If you are using Shorewall-shell or are upgrading from a Shorewall + version earlier than 4.0.0 then you will need to migrate to Shorewall-perl. + Shorewall-4.3.5 and later only use the perl-based compiler. +
+
Versions >= 4.2.0 - Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed + 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 @@ -158,7 +170,7 @@ The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) - has been changed from Yes to No. + has been changed from Yes to No. @@ -169,7 +181,7 @@ DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use - ipset-based zones instead. + ipset-based zones instead.