# Operating Shorewall and Shorewall Lite

Tom
Eastep
2004
2005
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.

This article applies to Shorewall 3.0 and later. If you are running a version of Shorewall earlier than Shorewall 3.0.0 then please see the documentation for that release.

## Operational Components

There are a number of files that comprise the operational components of Shorewall.

- `/sbin/shorewall` — The program that you use to interact with Shorewall. Normally the root user's PATH includes `/sbin` and the program can be run from a shell prompt by simply typing `shorewall` followed by a command.

  In some releases of KDE, the default configuration of the konsole program is brain dead with respect to the "Root Console". It executes the command "su" where it should execute "su -"; the latter will cause a login shell to be created which will in turn set PATH properly. You can correct this problem as follows:

  1. Click on "Settings" on the toolbar and select "Configure Konsole"

  2. Select the "Session" tab.

  3. Click on "Root Console"

  4. Change the Execute command from "su" to "su -"

  5. Click on "Save Session"

  6. Click on "Ok"

  To see a list of supported commands, use the `help` command:

      shorewall help

  To get further information about a particular command, follow `help` by the command:

      shorewall help start

- `/etc/shorewall` — The default directory where Shorewall looks for configuration files. See the sections entitled Additional Configuration Directories and Alternate Configuration Directories for information about how you can direct Shorewall to look in other directories.

- `/etc/init.d/shorewall` (`/etc/rc.d/rc.firewall` on Slackware) — The script run by `init` (the program responsible for startup and shutdown of your system) to start Shorewall at boot time and to stop Shorewall at shutdown.

- `/usr/share/shorewall/compiler` — In Shorewall 3.1 and later, the program that processes your Shorewall configuration files and creates a script to start, stop, restart, restore and clear the firewall.

- `/usr/share/shorewall/firewall` — In Shorewall 3.0 and earlier, the program responsible for configuring Netfilter based on your configuration files. In 3.2 and later versions, this program implements the add, delete, stop, clear and refresh commands.

- `/usr/share/shorewall/functions` — A library of Bourne Shell functions used by`/sbin/shorewall`, `/usr/share/shorewall/compiler` and `/usr/share/shorewall/firewall`.

There are similar components that comprise Shorewall Lite:

- `/sbin/shorewall-lite` — This is the program that you use to interact with Shorewall Lite.

- `/etc/shorewall-lite` — Directory where the configuration file for Shorewall Lite resides.

- `/var/lib/shorewall-lite/firewall` — The firewall program. It is generated and placed on the Shorewall LIte system through use of the `shorewall load` and `shorewall reload` commands on a system with the full Shorewall product installed.

  The 'firewall' script is in `/var/lib/shorewall-lite` in packages from shorewall.net. The package maintainers for the various distributions are free to choose the directory where the script will be stored under their distribution by changing the value of LITEDIR in /usr/share/shorewall[-lite]/configpath. See the output of `shorewall[-lite] show config` for the value of LITEDIR on your distribution.

  Example:

      gateway:~ # shorewall-lite show config
      Default CONFIG_PATH is /etc/shorewall-lite:/usr/share/shorewall-lite
      LITEDIR is /var/lib/shorewall-lite
      gateway:~ #

- `/usr/share/shorewall-lite/functions` — A library of Bourne Shell functions used by`/usr/share/shorewall-lite/shorewall`.

## Starting, Stopping and Clearing

As explained in the Introduction, Shorewall is not something that runs all of the time in your system. Nevertheless, for integrating Shorewall into your initialization scripts it is useful to speak of starting Shorewall and stopping Shorewall.

- Shorewall is started using the `shorewall start` command. Once the start command completes successfully, Netfilter is configured as described in your Shorewall configuration files. If there is an error during `shorewall start`, then if you have a saved configuration then that configuration is restored. Otherwise, an implicit `shorewall stop` is 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 is stopped using the `shorewall stop` command.

  The `shorewall stop` command does not remove all netfilter rules and open your firewall for all traffic to pass. It rather places your firewall in a safe state defined by the contents of your /etc/shorewall/routestopped file and the setting of ADMINISABSENTMINDED in /etc/shorewall/shorewall.conf.

- If you want to remove all Netfilter rules and open your firewall for all traffic to pass, use the `shorewall clear` command.

- If you change your configuration and want to install the changes, use the `shorewall restart` command.

For additional information, see the Shorewall State Diagram section.

## Tracing Command Execution

If you include the word trace as the first parameter to an `/sbin/shorewall` command that transfers control to `/usr/share/shorewall/firewall`, execution of the latter program will be traced to STDERR.

### Tracing `shorewall start`

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

## Having Shorewall Start Automatically at Boot Time

The .rpm, .deb and .tgz all try to configure your startup scripts so that Shorewall will start automatically at boot time. If you are using the `install.sh` script from the .tgz and it cannot determine how to configure automatic startup, a message to that effect will be displayed. You will need to consult your distribution's documentation to see how to integrate the `/etc/init.d/shorewall` script into the distribution's startup mechanism.

- Shorewall startup is disabled by default. Once you have configured your firewall, you can enable startup by editing `/etc/shorewall/shorewall.conf` and setting STARTUP_ENABLED=Yes.. Note: Users of the .deb package must rather edit `/etc/default/shorewall` and set startup=1.

- If you use dialup or some flavor of PPP where your IP address can change arbitrarily, you may want to start the firewall in your `/etc/ppp/ip-up.local` script. I recommend just placing `/sbin/shorewall restart` in that script.

## Saving a Working Configuration for Error Recovery and Fast Startup

Once you have Shorewall working the way that you want it to, you can use `shorewall save` to save the commands necessary to recreate that configuration in a restore script.

In its simplest form, the save command is just:

    shorewall save

That command creates the default restore script, `/var/lib/shorewall/restore`. The default may be changed using the RESTOREFILE option in /etc/shorewall/shorewall.conf. A different file name may also be specified in the `save` command:

    shorewall save <filename>

Where <filename> is a simple file name (no slashes).

Once created, the default restore script serves several useful purposes:

- If you change your configuration and there is an error when you try to restart Shorewall, the restore script will be run to restore your firewall to working order.

- Bootup is faster. The -f option of the start command (e.g., `shorewall -f start`) causes Shorewall to look for the default restore script and if it exists, the script is run. This is much faster than starting Shorewall using the normal mechanism of reading the configuration files and running `iptables` dozens or even hundreds of times. `By default, /etc/init.d/shorewall` (`/etc/rc.d/rc.firewall`) uses the -f option when it is processing a request to start Shorewall.

- The `shorewall restore` command can be used at any time to quickly configure the firewall.

      shorewall restore [ <filename> ]

  If no <filename> is given, the default restore script is used. Otherwise, the script `/var/lib/shorewall/<filename>` is used.

The ability to have multiple restore scripts means that you can save different Shorewall firewall configurations and switch between them quickly using the `restore` command.

Restore scripts may be removed using the `shorewall forget` command:

    shorewall forget [ <filename> ]

If no <filename> is given, the default restore script is removed. Otherwise, `/var/lib/shorewall/<filename>` is removed (of course, you can also use the Linux `rm` command from the shell prompt to remove these files).

## Additional Configuration Directories

The CONFIG_PATH setting in `/etc/shorewall/shorewall.conf` determines where Shorewall looks for configuration files. The default setting is CONFIG_PATH=`/etc/shorewall`:`/usr/share/shorewall` which means that `/etc/shorewall` is searched first and if the file is not found then `/usr/share/shorewall` is searched. You can change the value of CONFIG_PATH to cause additional directories to be searched but CONFIG_PATH should always include both `/etc/shorewall` and `/usr/share/shorewall`.

When an alternate configuration directory is specified as described in the next section, that directory is searched before those directories listed in CONFIG_PATH.

Example - Search `/etc/shorewall`, `/etc/shorewall/actiondir` and `/usr/share/shorewall` in that order:

    CONFIG_PATH=/etc/shorewall:/etc/shorewall/actiondir:/usr/share/shorewall

The above is the setting that I once used to allow me to place all of my user-defined 'action.' files in `/etc/shorewall/actiondir`.

## Alternate Configuration Directories

As explained above, Shorewall normally looks for configuration files in the directories specified by the CONFIG_PATH option in `/etc/shorewall/shorewall.conf`. The `shorewall start`, `shorewall restart`, `shorewall check`, and `shorewall try` commands allow you to specify an additional directory for Shorewall to check before looking in the directories listed in CONFIG_PATH.

         shorewall {start|restart|check} <configuration-directory>
         shorewall try <configuration-directory> [ <timeout> ]

If a <configuration-directory> is specified, each time that Shorewall is going to read a file, it will first look in the <configuration-directory> . If the file is present in the <configuration-directory>, that file will be used; otherwise, the directories in the CONFIG_PATH will be searched. When changing the configuration of a production firewall, I recommend the following:

- If you haven't saved the current working configuration, do so using `shorewall save`.

- `mkdir /etc/test`

- `cd /etc/test`

- <copy any files that you need to change from /etc/shorewall to . and change them here>

- `shorewall check ./`

- <correct any errors found by check and check again>

- `shorewall restart ./`

If the `restart` fails, your configuration will be restored to it's state at the last `shorewall save`.

When the new configuration works then just:

- `cp -f * /etc/shorewall`

- `cd`

- `rm -rf /etc/test`

- `shorewall save`

## Command Reference

The general form of a command in Shorewall 3.0 is:

> `shorewall [ <options> ] <command> [ <argument> ... ]`

> Available options are:

> -c <directory>

>   Specifies an alternate configuration directory.

> -f

>   Specifies fast restart. See the `start` command below.

> -n

>   Prevents the command from changing the firewall system's routing configuration.

> -q

>   In Shorewall versions prior to 3.2.0, causes some of the output to be suppressed.

>   In 3.2.0 and later, reduces the verbosity level (see VERBOSITY setting in shorewall.conf). May be repeated (e.g., "-qq") with each instance reducing the verbosity level by one.

> -v

>   In Shorewall versions prior to 3.2.0, causes Ethernet MAC addresses to be included in log message displays.

>   In 3.2.0 and later, increases the verbosity level (see VERBOSITY setting in shorewall.conf). May be repeated (e.g., "-qq") with each instance increasing the verbosity level by one.

> -x

>   Causes all iptables -L commands to display actual packet and byte counts.

The general form of a command in Shorewall 3.1 and later is:

> `shorewall [ <options> ] <command> [ <command options> ] [ <argument> ... ]`

> For compatibility, Shorewall 3.1 and later accept all of the 3.0 command options. In addition, 3.1 defines some new options and also defines command-specific options that are entered after the command on the run-line.

> New options are:

> -t

>   All progress messages are timestamped with the date and time.

> In addition, the `-q` and `-v` options may be repeated to make the output less or more verbose respectively. The default level of verbosity is determined by the setting of the VERBOSITY option in `/etc/shorewall/shorewall.conf`.

> For Shorewall Lite, the general command form is:

> `shorewall-lite [ <options> ] <command> [ <command options> ] [ <argument> ... ]`

> where the options are the same as with Shorewall.

Following in alphabetical order are the supported commands. Except as noted, `/sbin/shorewall-lite` supports the same commands as `/sbin/shorewall`.

add (Not supported by Shorewall Lite)

  `shorewall add <interface>[:<host-list>] … <zone>`

  A <host-list> is a comma-separated list whose entries are:

  - A host or network address

  - The name of a bridge port

  - The name of a bridge port followed by a colon (":") and a host or network address.

  Adds an interface (and list of hosts if included) to a dynamic zone usually used with VPN's.

  Example: `shorewall add ipsec0:192.0.2.24 vpn1`

  adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1.

allow

  `shorewall[-lite] allow <address> ...`

  Re-enables receipt of packets from hosts previously blacklisted by a drop or reject command.

  Shorewall allow, drop, rejct and save implement dynamic blacklisting.

check (Not supported by Shorewall Lite)

  `shorewall check [ <configuration-directory> ]`

  Performs a cursory validation of the zones, interfaces, hosts, rules, policy, masq, blacklist, proxyarp, nat and provider files. Use this if you are unsure of any edits you have made to the shorewall configuration. See above for a recommended way to make changes.

clear

  `shorewall[-lite] clear`

  Clear will remove all rules and chains installed by Shorewall. The firewall is then wide open and unprotected. Existing connections are untouched. Clear is often used to see if the firewall is causing connection problems.

compile (Shorewall 3.1 and later - Not supported by Shorewall Lite)

  `shorewall compile [ -e ] [ <directory name> ] <path name>`

  Compiles the current configuration into the executable file <path name>. If <path name> names a file in /var/lib/shorewall then the file may be executed using the "restore" command.

  When -e is specified, the compilation is being performed on a system other than where the compiled script will run under Shorewall Lite. This option disables certain configuration options that require the script to be compiled where it is to be run and allows the script to be run on a system where Shorewall Lite is installed. The file /etc/shorewall/capabilities must be present when -e is used; that file specifies the iptables/kernel capabilities on the target system.

  The compiled script is a complete program that supports the following commands:

  > - `<program> [ -q ] [ -v ] [ -n ] start`
  > - `<program> [ -q ] [ -v ] [ -n ] stop`
  > - `<program> [ -q ] [ -v ] [ -n ] clear`
  > - `<program> [ -q ] [ -v ] [ -n ] restart`
  > - `<program> [ -q ] [ -v ] [ -n ] status`
  > - `<program> [ -q ] [ -v ] [ -n ] version`

  The options have their same meaning is when they are passed to `/sbin/shorewall` itself.

  For additional information about the `compile` command, see this article.

delete (Not supported by Shorewall Lite)

  `shorewall delete <interface>[:<host-list>] … <zone>`

  A <host-list> is a comma-separated list whose entries are:

  - A host or network address

  - The name of a bridge port

  - The name of a bridge port followed by a colon (":") and a host or network address.

  Deletes the specified interface (and host list if included) from the specified zone.

  Example:

  `shorewall delete ipsec0:192.0.2.24 vpn1`

  deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1

drop

  `shorewall[-lite] drop <address> ...`

  Causes packets from the specified <address> to be ignored

dump

  `shorewall[-lite] dump`

  Produce a verbose report about the firewall.

  When -x is given, that option is also passed to iptables to display actual packet and byte counts.

export (Shorewall 3.2.3 and later - Not supported by Shorewall Lite)

  `export [ <directory1> ] [<user>@]<system>:[<directory2>]`

  If <directory1> is omitted, the current working directory is assumed.

  Allows a non-root user to compile a shorewall script and stage it on a system (provided that the user has access to the system via ssh). The command is equivalent to:

  - `/sbin/shorewall compile -e <directory1> <directory1>/firewall &&\`
  - `scp <directory1>/firewall <directory1>/firewall.conf [<user>@]<system>:[<directory2>]`

  In other words, the configuration in the specified (or defaulted) directory is compiled to a file called `firewall` in that directory. If compilation succeeds, then `firewall and firewall.conf` are copied to <system> using scp.

forget

  `shorewall[-lite] forget [ <filename> ]`

  Deletes`/var/lib/shorewall/<filename>`. If no <filename> is given then the file specified by RESTOREFILE in /etc/shorewall/shorewall.conf is removed.

help

  `shorewall[-lite] help [<command> | host | address ]`

  Display helpful information about the shorewall commands.

hits

  `shorewall[-lite] hits`

  Produces several reports about the Shorewall packet log messages in the current log file specified by the LOGFILE option in /etc/shorewall/shorewall.conf.

ipcalc

  `shorewall[-lite] ipcalc { <address> <mask> | <address>/<vlsm> }`

  Ipcalc displays the network address, broadcast address, network in CIDR notation and netmask corresponding to the input[s].

  Example:

  `shorewall[-lite] ipcalc 192.168.1.0/24`

iprange

  `shorewall[-lite] iprange <address1>-<address2>`

  Iprange decomposes the specified range of IP addresses into the equivalent list of network/host addresses.

load (Added in Shorewall 3.2.0 RC4 -- not supported by Shorewall Lite)

  `load [ -s ] [ -c ] [ -r <root user name> ] [ <directory> ] <system>`

  If <directory> is omitted, the current working directory is assumed.

  Allows a non-root user to compile a shorewall script and install it on a system (provided that the user has root access to the system via ssh). The command is equivalent to:

  - `/sbin/shorewall compile -e <directory> <directory>/firewall &&\`
  - `scp <directory>/firewall <directory>/firewall.conf root@<system>:/var/lib/shorewall-lite/ &&\`
  - `ssh root@<system> '/sbin/shorewall-lite start'`

  In other words, the configuration in the specified (or defaulted) directory is compiled to a file called `firewall` in that directory. If compilation succeeds, then `firewall` is copied to <system> using scp. If the copy succeeds, Shorewall Lite on <system> is started via ssh.

  The 'firewall' script is in `/var/lib/shorewall-lite` in packages from shorewall.net. The package maintainers for the various distributions are free to choose the directory where the script will be stored under their distribution by changing the value of LITEDIR in /usr/share/shorewall[-lite]/configpath. See the output of `shorewall[-lite] show config` for the value of LITEDIR on your distribution.

  Example:

      gateway:~ # shorewall-lite show config
      Default CONFIG_PATH is /etc/shorewall-lite:/usr/share/shorewall-lite
      LITEDIR is /var/lib/shorewall-lite
      gateway:~ #

  Example: `shorewall load gateway`

  If the -s option (added in Shorewall 3.2.2) is given and the remote `/sbin/shorewall-lite start` command succeeds then the configuration on the remote system is saved using the command

  - `ssh root@<system> '/sbin/shorewall-lite save'`

  The -c option was added in Shorewall 3.2.6. It causes the capabilities of the remote system to be collected and stored in a `capabilities` file in the specified (or defaulted) <directory> before the configuration is compiled.

  The -r option was added in Shoreawll 3.2.7/3.3.6 and named the 'root' user on the remote <system>. This option must be used if the root user on <system> is named other than "root".

logdrop

  `shorewall[-lite] logdrop <address> ...`

  Causes packets from the specified <address> to be ignored and logged

logwatch

  `shorewall[-lite] logwatch [ -m ] [<refresh interval>]`

  Monitors the log file specified by theLOGFILE option in /etc/shorewall/shorewall.conf and produces an audible alarm when new Shorewall messages are logged.

  The '-m' option is available in Shorewall version 3.2.0 Beta5 and later and causes the MAC address of each packet source to be displayed if that information is available.

logreject

  `shorewall[-lite] logreject <address> ...`

  Causes packets from the specified <address> to be rejected and logged

refresh (Not supported by Shorewall Lite)

  `shorewall refresh`

  The rules involving the broadcast addresses of firewall interfaces, the black list and ECN control rules are recreated to reflect any changes made to your configuration files. Shorewall versions prior to 3.2.0 Beta 5 also recreate the traffic shaping rules as part of processing the `refresh` command. Existing connections are untouched. If -q is specified, less detail is displayed making it easier to spot warnings.

reject

  `shorewall[-lite] reject <address> ...`

  Causes packets from the specified <address>s to be rejected

reload (Added in Shorewall 3.2.0 RC4 -- not supported by Shorewall Lite)

  `reload [ -s ] [ -c ] [ -r <root user name> ] [ <directory> ] <system>`

  If <directory> is omitted, the current working directory is assumed.

  Allows a non-root user to compile a shorewall script and install it on a system (provided that the user has root access to the system via ssh). The command is equivalent to:

  - `/sbin/shorewall compile -e <directory> <directory>/firewall &&\`
  - `scp <directory>/firewall <directory>/firewall root@<system>:/var/lib/shorewall-lite/ &&\`
  - `ssh root@<system> '/sbin/shorewall-lite restart'`

  In other words, the configuration in the specified (or defaulted) directory is compiled to a file called `firewall` in that directory. If compilation succeeds, then `firewall` is copied to <system> using scp. If the copy succeeds, Shorewall Lite on <system> is restarted via ssh.

  The 'firewall' script is in `/var/lib/shorewall-lite` in packages from shorewall.net. The package maintainers for the various distributions are free to choose the directory where the script will be stored under their distribution by changing the value of LITEDIR in /usr/share/shorewall[-lite]/configpath. See the output of `shorewall[-lite] show config` for the value of LITEDIR on your distribution.

  Example:

      gateway:~ # shorewall-lite show config
      Default CONFIG_PATH is /etc/shorewall-lite:/usr/share/shorewall-lite
      LITEDIR is /var/lib/shorewall-lite
      gateway:~ #

  Example: `shorewall reload gateway`

  If the -s option (added in Shorewall 3.2.2) is given and the remote `/sbin/shorewall-lite restart` command succeeds then the configuration on the remote system is saved using the command

  - `ssh root@<system> '/sbin/shorewall-lite save'`

  The -c option was added in Shorewall 3.2.6. It causes the capabilities of the remote system to be collected and stored in a `capabilities` file in the specified (or defaulted) <directory> before the configuration is compiled.

  The -r option was added in Shoreawll 3.2.7/3.3.6 and named the 'root' user on the remote <system>. This option must be used if the root user on <system> is named other than "root".

reset

  `shorewall[-lite] reset`

  All the packet and byte counters in the firewall are reset.

restart

  `shorewall[-lite] restart <configuration-directory>`

  Restart is similar to `shorewall stop` followed by `shorewall start`. Existing connections are maintained. If -q is specified, less detail is displayed making it easier to spot warnings

restore

  `shorewall[-lite] restore [ <filename> ]`

  Restore Shorewall to a state saved using the `shorewall save` command Existing connections are maintained. The <filename> names a restore file in `/var/lib/shorewall` created using `shorewall save`; if no <filename> is given then Shorewall will be restored from the file specified by the RESTOREFILE option in /etc/shorewall/shorewall.conf.

safe-restart (Not supported by Shorewall Lite)

  `shorewall safe-restart [ <filename> ]`

  Only allowed if Shorewall is running. The current configuration is saved in `/var/lib/shorewall/safe-restart` (see the `save` command below) that a restart is done. You will then be prompted asking if you want to accept the new configuration or not. If you answer "n" or if you fail to answer within 60 seconds (such as when your new configuration has disabled communication with your terminal), the configuration is restored from the saved configuration.

safe-start (Not supported by Shorewall Lite)

  `shorewall safe-start [ <filename> ]`

  Shorewall is started normally. You will then be prompted asking if everything went all right. If you answer "n" or if you fail to answer within 60 seconds (such as when your new configuration has disabled communication with your terminal), a `shorewall clear` is performed for you.

save

  `shorewall[-lite] save [ <filename> ]`

  The dynamic data is stored in /var/lib/shorewall/save. The state of the firewall is stored in `/var/lib/shorewall/<filename>` for use by the `shorewall[-lite] restore` and `shorewall[-lite] -f start` commands. If <filename> is not given then the state is saved in the file specified by the RESTOREFILE option in /etc/shorewall/shorewall.conf.

show

  `shorewall show actions (Not supported by Shorewall Lite)` — produces a list of actions available on the system.

  `shorewall[-lite] show [ <chain> [ <chain> ...] |classifiers|connections|log|nat|tc|tos]`

  `shorewall[-lite] show <chain> [ <chain> ... ]` - produce a verbose report about the Netfilter chain(s). (`iptables -L chain -n -v`)

  `shorewall[-lite] show mangle` - produce a verbose report about the mangle table. (`iptables -t mangle -L -n -v`)

  `shorewall[-lite] show nat` - produce a verbose report about the nat table. (`iptables -t nat -L -n -v`)

  `shorewall[-lite] show [- m ] log` - display the last 20 packet log entries. The '-m' option is available in Shorewall version 3.2.0 Beta5 and later and causes the MAC address of each packet source to be displayed if that information is available.

  `shorewall[-lite] show capabilities` - Displays your kernel/iptables capabilities

  `shorewall[-lite] show connections` - displays the IP connections currently being tracked by the firewall.

  `shorewall[-lite] show classifiers` - displays information about the traffic control/shaping classifiers.

  `shorewall[-lite] show config` - displays the default CONFIG_PATH and LITEDIR for your distribution.

  `shorewall [ -x ] show macros (Not supported by Shorewall Lite)` — produces a list of macros available on the system.

  `shorewall[-lite] show tc` - displays information about the traffic control/shaping configuration.

  `shorewall[-lite] show zones` — Displays the composition of each zone.

  When -x is given, that option is also passed to iptables to display actual packet and byte counts.

start

  `shorewall[-lite] [ -f ] start [ <configuration-directory> ]`

  Start shorewall. Existing connections through shorewall managed interfaces are untouched. New connections will be allowed only if they are allowed by the firewall rules or policies. If -f is specified, the saved configuration specified by the RESTOREFILE option in /etc/shorewall/shorewall.conf will be restored if that saved configuration exists

stop

  `shorewall[-lite] stop`

  Stops the firewall. All existing connections, except those listed in `/etc/shorewall/routestopped` or permitted by the ADMINISABSENTMINDED option in /etc/shorewall/shorewall.conf, are taken down. The only new traffic permitted through the firewall is from systems listed in `/etc/shorewall/routestopped` or by ADMINISABSENTMINDED.

status

  `shorewall[-lite] status`

  Produce a short report about the firewall's status and state relative to the diagram below.

try (Not supported by Shorewall Lite)

  `shorewall try <configuration-directory> [ <timeout> ]`

  Restart shorewall using the specified configuration. If an error occurs during the restart, then another shorewall restart is performed using the default configuration. If a timeout is specified then the restart is always performed after the timeout occurs and uses the default configuration.

  When restarting using the default configuration, if the default restore script (as specified by the RESTOREFILE setting in /etc/shorewall/shorewall.conf) exists. then that script is used.

  The `try` command is deprecated in Shorewall 3.0 and 3.2. A better approach to testing new configurations is:

  > `shorewall save`

  > `shorewall restart <configuration-directory>` [ `&& sleep <timeout> && shorewall restore` ]

  > fix problems

  > `shorewall restart <configuration-directory>` [ `&& sleep <timeout> && shorewall restore` ]

  > fix problems

  > …

  Beginning with Shorewall version 3.3.6, the `try` command has new and improved semantics as follows:

  > If Shorewall is started then the firewall state is saved to a temporary saved configuration (`/var/lib/shorewall/.try`). Next, if Shorewall is currently started then a `restart` command is issued; otherwise, a `start` command is performed. if an error occurs during the compliation phase of the `restart` or `start`, the command terminates without changing the Shorewall state. If an error occurs during the `restart` phase, then a shorewall restore is performed using the saved configuration. If an error occurs during the `start` phase, then Shorewall is cleared. If the start/restart succeeds and a <timeout> is specified then a `clear` or `restore` is performed after <timeout> seconds.

version

  `shorewall[-lite] version`

  Show the current shorewall version

## Shorewall State Diagram

The Shorewall State Diargram is depicted below.

/sbin/shorewall Command | Resulting /usr/share/shorewall/firewall Command | Effect if the Command Succeeds
--- | --- | ---
shorewall start | firewall start | The system filters packets based on your current Shorewall Configuration
shorewall stop | firewall stop | Only traffic to/from hosts listed in /etc/shorewall/hosts is passed to/from/through the firewall. If ADMINISABSENTMINDED=Yes in /etc/shorewall/shorewall.conf then in addition, all existing connections are retained and all connection requests from the firewall are accepted.
shorewall restart | firewall restart | Logically equivalent to firewall stop;firewall start
shorewall add | firewall add | Adds a host or subnet to a dynamic zone
shorewall delete | firewall delete | Deletes a host or subnet from a dynamic zone
shorewall refresh | firewall refresh | Reloads rules dealing with static blacklisting, traffic control and ECN.
shorewall reset | firewall reset | Resets traffic counters
shorewall clear | firewall clear | Removes all Shorewall rules, chains, addresses, routes and ARP entries.
shorewall try | firewall -c <new configuration> restart If unsuccessful then firewall start (standard configuration) If timeout then firewall restart (standard configuration) |

The only time that a program other than `/usr/share/shorewall[-lite[/firewall` performs a state transition itself is when the `shorewall[-lite] restore` command is executed. In that case, the `/var/lib/shorewall[-lite]/restore` program sets the state to "Started".

### Notes for Shorewall 3.2.0 and Later

With any command that involves compilation, there is no state transition while the compiler is running. If compilation fails, the state remains unchanged.

Also, `shorewall start` and `shorewall restart` involve compilation followed by execution of the compiled script. So it is the compiled script that performs the state transition in these commands rather than `/usr/share/shorewall/firewall`.

The compiled script is placed in `/var/lib/shorewall` and is named either `.start` or `.restart` depending on the command.