Copyright © 2004, 2005 Thomas M. Eastep
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 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”.
2007/07/19
Table of Contents
Shorewall can produce a wide variety of error messages when a problem is detected with your configuration. This article attempts to explain the cause of and cures for some of these messages.
Some error messages are produced by the /sbin/shorewall utility. These messages are detailed in this section.
This means that you have specified a restore file name with a "/". Restore files must be simple file names with no slashes.
The files /usr/share/shorewall/firewall
and/or /usr/share/shorewall/version do not
exist.
The named file in /var/lib/shorewall
exists but is not executable.
You have specified either save or
restore-base as the name of a restore file --
those names are reserved for use by Shorewall.
During processing of a shorewall save command, the iptables-save command failed.
The shorewall start and shorewall
restart commands create a file called
/var/lib/shorewall/restore-base which forms the
basis for creating a restore file using shorewall
save. This error message is issued when shorewall
save is not able to find that file.
The IPTABLES option in
/etc/shorewall/shorewall.conf specifies a file
that is not executable.
There is no executable file named "iptables" in any directory in $PATH.
The SHOREWALL_SHELL option in
/etc/shorewall/shorewall.conf names does not
name an executable file.
The restore file (<file>) specified or implied in a shorewall save command already exists but is not executable (and hence cannot be a value restore file). Either remove/rename the file or specify a different file name.
The program /usr/share/shorewall/firewall is
responsible for parsing the Shorewall configuration files and for creating
and changing the Netfilter configuration. Some of the error messages
generated by this program are listed below.
The zone name in the ZONE column of
/etc/shorewall/zones may not start with a colon
(":").
The firewall zone may not be defined to have zones nested within it.
When defining nested zones in
/etc/shorewall/zones, the parent zone must be
defined before any zones nested inside of it.
Zone names are restricted to 5 characters or less in length.
The zone name quoted in the error message begins with a digit -- zone names must begin with an alphabetic character.
The names "none" and "all" are reserved and may not be used as
zone names in /etc/shorewall/zones.
There are two records in
/etc/shorewall/zones that define the named
zone.
You have defined a zone of type ipsec in
/etc/shorewall/zones or have specified the
ipsec option in an /etc/shorewall/hosts record
but your kernel and/or iptables don't include policy match support
-- see this article for
details.
You have defined a zone of type firewall to be nested inside another zone. Shorewall does not support such nesting.
The zone of type firewall may
not have any options specified in the OPTIONS, IN OPTIONS or OUT
OPTIONS columns of /etc/shorewall/zones.
You may have only one record in
/etc/shorewall/zones that has type firewall.
You must define at least one ipv4 or ipsec zone in
/etc/shorewall/zones.
You must define one (and only one) zone if type firewall in
/etc/shorewall/zones.
Shorewall-assigned packet and connection marks are limited to the range 1-255.
The zone named in the message is defined to be associated with
an interface in /etc/shorewall/interfaces yet
it also has an entry for that same interface in
/etc/shorewall/hosts.
The zone named in the ZONE column of the listed record from
/etc/shorewall/interfaces or
/etc/shorewall/hosts is not defined in
/etc/shorewall/zones.
The ZONE column of a record in
/etc/shorewall/interfaces was empty ("-"). Such
interfaces may not specify the routeback option.
The interface name in the INTERFACE column is a wild-card (ends with "+"). Such interfaces may not specify the detectnets option.
The named interface has two entries in
/etc/shorewall/interfaces.
The interface name contains a colon (":") or is "+". If the name includes a ":", you probably need to read this article.
The <interface> named in the message is configured with an IP address that is reserved by RFC 1918 -- that address is incompatible with the norfc1918 interface option.
The <interface> name listed in the
<record> from
/etc/shorewall/hosts was not defined in
/etc/shorewall/interfaces.
The contests of the HOST(S) column in a record from
/etc/shorewall/hosts does not follow the proper
syntax for that column in that it doesn't contain at least one colon
(":"). See the /etc/shorewall/hosts
documentation.
The named interface appears in /etc/shorewall/hosts and
appears as a bridge port (after a colon) but is also defined in
/etc/shorewall/interfaces.
The named zone appears in the /etc/shorewall/policy file but not in the /etc/shorewall/zones file.
Shorewall does not support a policy of NONE when the source or destination zone is the firewall itself.
Shorewall does not support a policy of NONE when the source or destination zone is "all".
There is an earlier record in the file with the same <source zone> and <destination zone>
You have specified DETECT_DNAT_ADDRS=Yes in /etc/shorewall/shorewall.conf and Shorewall is unablee to determine the IP address of the named <interface>. Be sure that the interface is started before starting Shorewall or set DETECT_DNAT_ADDRS=No.
The listed <zone> name appears in
the GATEWAY ZONE column of the listed
<record> from
/etc/shorewall/tunnels but is not defined in
/etc/shorewall/zones.
The named <interface> appears in a
record in /etc/shorewall/maclist yet that
interface's record in /etc/shorewall/interfaces
does not specify the maclist option
and no record in /etc/shorewall/hosts that
names that interface includes the maclist option.
You have specified the maclist option for this interface but the command ip list show <interface> fails.
The interface appears in a configuration file but is not
defined in /etc/shorewall/interfaces.
You have set BRIDGING=Yes in
/etc/shorewall/shorewall.conf but it appears
that your kernel and/or iptables do not have physdev match
support.
The <action> contains one of the following characters: ".", "-", or "%". Those characters are not allowed in an action name.
The value being passed to a parameterized macro is not ACCEPT, DROP, REJECT, LOG, QUEUE or CONTINUE.
The specified <action name> has an entry in
/usr/share/shorewall/actions.std or in
/etc/shorewall/actions but the corresponding
action file does not exist on the CONFIG_PATH.
You have BRIDGING=No in
/etc/shorewall/shorewall.conf and the
<interface> given in a rule does not
match an entry in
/etc/shorewall/interfaces.
In earlier Shorewall versions, the ORIGINAL DEST column allowed following the original destination IP address with ":" and an address to use as the source of the forwarded connection request. Now that /etc/shorewall/masq supports qualification of SNAT rules by protocol and port, this feature is no longer required and has been deimplemented.
The SOURCE column has the firewall zone name immediately followed by "!". This syntax is use to exclude a subzone and Shorewall currently doesn't support subzones of the firewall zone.
Netfilter (and hence Shorewall) does not allow qualification of a rule by destination source IP address.
The named <action> will be ACCEPT+ or NONAT. These actions are inforced in part in the PREROUTING nat chain where the destination interface is not yet known (because the packet has not yet been routed). As a result, the DESTINATION column may not contain an interface name.
The <rule> specifies a server address that is different from the ORIGINAL DEST address and/or it specifies a server port that is different from the destination port but the ACTION is neither DNAT[-] nor REJECT[-].
The SOURCE column is of one of the forms <zone>:, :<qualifier> or :.
In DNAT[-] and REDIRECT[-] rules, you can have a SOURCE of the form <zone>:<net1>!<net2>. This means <net1> in the <zone> zone except for <net2>. This syntax is not available with other ACTIONs.
The USER/GROUP column may only have and entry if the SOURCE is the firewall zone.
The DEST column is of one of the forms <zone>:, :<qualifier> or :.
The zone given in the SOURCE column was not defined in
/etc/shorewall/zones.
The zone given in the DEST column was not defined in
/etc/shorewall/zones.
If the policy from zone z1 to zone z2 is NONE that means that Shorewall sets up no infrastructure to handle traffic from z1 to z2. Consequently, you cannot have any rules that control traffic from z1 to z2.
The ACTION column contains an action that is not one of the
built-in actions and it is not defined in
/etc/shorewall/actions or in
/usr/share/shorewall/actions.std.
You have specified <interface> in
the SUBNET column of /etc/shorewall/masq which
means that Shorewall is supposed to determine the network(s) routed
through that interface. To do that, Shorewall issues the command
ip addr ls dev <interface> and that command
failed. This usually means that you are trying to start Shorewall
before the <interface> is brought
up.
There is no policy defined in
/etc/shorewall/policy for connections from zone
<z1> to zone
<z2>.
This sections describes some of the more common warnings generated by Shorewall.
This means that the interface named in the SUBNET column of
/etc/shorewall/masq has the default route. This
almost always means that you have the contents of the INTERFACE and
SUBNET columns reversed.
This warning alerts you to the fact tha <zone> is
defined in /etc/shorewall/zones but has no
corresponding entries in
/etc/shorewall/interfaces or in
/etc/shorewall/hosts.
If you need help understanding that warning message then you probably need to take up another hobby or line of work.
By far the most asked about iptables error messages are:
This almost always means that you are trying to use a Shorewall feature that your iptables and/or kernel do not support. Beginning with version 2.2.0, Shorewall follows this message with a copy of the iptables command that is failing. Most commonly, the problem is that one of the match types (keyword following "-m" in the command) isn't supported by your iptables/kernel. The output of "shorewall show capabilities" shows you what your iptables/kernel support:
gateway:~# shorewall show capabilities Shorewall has detected the following iptables/netfilter capabilities: NAT: Available Packet Mangling: Available Multi-port Match: Available Extended Multi-port Match: Available Connection Tracking Match: Available Packet Type Match: Available Policy Match: Available Physdev Match: Available IP range Match: Available Recent Match: Available Owner Match: Available Ipset Match: Available ROUTE Target: Not available Extended MARK Target: Available CONNMARK Target: Available Connmark Match: Available Raw Table: Available gateway:~#
Answer: 99.999% of the time, this error is caused by a mismatch between your iptables and kernel.
Your iptables must be compiled against a kernel source tree that is Netfilter-compatible with the kernel that you are running.
If you rebuild iptables using the defaults and install it, it will be installed in /usr/local/sbin/iptables. As shown above, you have the IPTABLES variable in shorewall.conf set to "/sbin/iptables".