Copyright © 2002, 2003, 2004 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”.
2004/03/13
Table of Contents
It is important that you read all of the sections on this page where the version number mentioned in the section title is later than what you are currently running.
In the descriptions that follows, the term group refers to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be a host address) accessed through a particular interface.
Examples:
| eth0:0.0.0.0/0 |
| eth2:192.168.1.0/24 |
| eth3:192.0.2.123 |
You can use the shorewall check command to see the groups associated with each of your zones.
The 'dropunclean' and 'logunclean' interface options are no longer supported. If either option is specified in /etc/shorewall/interfaces, a threatening message will be generated.
The NAT_BEFORE_RULES option has been removed from shorewall.conf. The behavior of Shorewall 2.0 is as if NAT_BEFORE_RULES=No had been specified. In other words, DNAT rules now always take precidence over one-to-one NAT specifications.
The default value for the ALL INTERFACES column in /etc/shorewall/nat has changed. In Shorewall 1.*, if the column was left empty, a value of "Yes" was assumed. This has been changed so that a value of "No" is now assumed.
The following files don't exist in Shorewall 2.0:
| /etc/shorewall/common.def |
| /etc/shorewall/common |
| /etc/shorewall/icmpdef |
| /etc/shorewall/action.template (moved to /usr/share/shorewall/action.template) |
The /etc/shorewall/action file now allows an action to be designated as the "common" action for a particular policy type by following the action name with ":" and the policy (DROP, REJECT or ACCEPT).
The file /usr/share/shorewall/actions.std has been added to define those actions that are released as part of Shorewall 2.0 In that file are two actions as follows:
| Drop:DROP |
| Reject:REJECT |
The “Drop” action is the common action for DROP policies while the “Reject” action is the default action for REJECT policies. These actions will be performed on packets prior to applying the DROP or REJECT policy respectively. In the first release, the difference between "Reject" and "Drop" is that "Reject" REJECTs SMB traffic while "Drop" silently drops such traffic.
As described above, Shorewall allows a common action for ACCEPT policies but does not specify such an action in the default configuration.
For more information see the User-defined Action Page.
The /etc/shorewall directory no longer contains users file or a usersets file. Similar functionality is now available using user-defined actions.
Now, action files created by copying /usr/share/shorewall/action.template may now specify a USER and or GROUP name/id in the final column just like in the rules file (see below). It is thus possible to create actions that control traffic from a list of users and/or groups.
The last column in /etc/shorewall/rules is now labeled USER/GROUP and may contain:
| [!]<user number>[:] |
| [!]<user name>[:] |
| [!]:<group number> |
| [!]:<group name> |
| [!]<user number>:<group number> |
| [!]<user name>:<group number> |
| [!]<user inumber>:<group name> |
| [!]<user name>:<group name> |
The meaning of ROUTE_FILTER=Yes has changed. Previously this setting was documented as causing route filtering to occur on all network interfaces; this didn't work. Beginning with this release, ROUTE_FILTER=Yes causes route filtering to occur on all interfaces brought up while Shorewall is running. This means that it may be appropriate to set ROUTE_FILTER=Yes and use the routefilter option in /etc/shorewall/interfaces entries.
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed from shorewall.conf. These capabilities are now automatically detected by Shorewall.
An undocumented feature previously allowed entries in the host file as follows:
zone eth1:192.168.1.0/24,eth2:192.168.2.0/24 |
This capability was never documented and has been removed in 1.4.6 to allow entries of the following format:
zone eth1:192.168.1.0/24,192.168.2.0/24 |
If you are upgrading from 1.4.3 and have set the LOGMARKER variable in /etc/shorewall/shorewall.conf, then you must set the new LOGFORMAT variable appropriately and remove your setting of LOGMARKER.
If you have zone names that are 5 characters long, you may experience problems starting Shorewall because the --log-prefix in a logging rule is too long. Upgrade to Version 1.4.4a to fix this problem.
There are some cases where you may want to handle traffic from a particular group to itself. While I personally think that such a setups are ridiculous, there are two cases covered in this documentation where it can occur:
If you have either of these cases, you will want to review the current documentation and change your configuration accordingly.
Beginning with Version 1.4.1, traffic between groups in the same zone is accepted by default. Previously, traffic from a zone to itself was treated just like any other traffic; any matching rules were applied followed by enforcement of the appropriate policy. With 1.4.1 and later versions, unless you have explicit rules for traffic from Z to Z or you have an explicit Z to Z policy (where "Z" is some zone) then traffic between the groups in zone Z will be accepted. If you do have one or more explicit rules for Z to Z or if you have an explicit Z to Z policy then the behavior is as it was in prior versions.
If you have a Z Z ACCEPT policy for a zone to allow traffic between two interfaces to the same zone, that policy can be removed and traffic between the interfaces will traverse fewer rules than previously.
If you have a Z Z DROP or Z Z REJECT policy or you have Z->Z rules then your configuration should not require any change.
If you are currently relying on a implicit policy (one that has "all" in either the SOURCE or DESTINATION column) to prevent traffic between two interfaces to a zone Z and you have no rules for Z->Z then you should add an explicit DROP or REJECT policy for Z to Z.
Sometimes, you want two separate zones on one interface but you don't want Shorewall to set up any infrastructure to handle traffic between them.
Example 1. The zones, interfaces and, hosts file contents
/etc/shorewall/zones z1 Zone1 The first Zone z2 Zone2 The second Zone /etc/shorewall/interfaces z2 eth1 192.168.1.255 /etc/shorewall/hosts z1 eth1:192.168.1.3 |
Here, zone z1 is nested in zone z2 and the firewall is not going to be involved in any traffic between these two zones. Beginning with Shorewall 1.4.1, you can prevent Shorewall from setting up any infrastructure to handle traffic between z1 and z2 by using the new NONE policy:
Note that NONE policies are generally used in pairs unless there is asymetric routing where only the traffic on one direction flows through the firewall and you are using a NONE polciy in the other direction.
In Version 1.4.1, Shorewall will never create rules to deal with traffic from a given group back to itself. The multi interface option is no longer available so if you want to route traffic between two subnetworks on the same interface then I recommend that you upgrade to Version 1.4.2 and use the routeback interface or host option.
Shorewall >=1.4.0 requires the iproute package ('ip' utility).
Unfortunately, some distributions call this package iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:
error: failed dependencies:iproute is needed by shorewall-1.4.0-1 |
This may be worked around by using the --nodeps option of rpm (rpm -Uvh --nodeps your_shorewall_rpm.rpm).
If you are upgrading from a version < 1.4.0, then:
The noping and forwardping interface options are no longer supported nor is the FORWARDPING option in shorewall.conf. ICMP echo-request (ping) packets are treated just like any other connection request and are subject to rules and policies.
Interface names of the form <device>:<integer> in /etc/shorewall/interfaces now generate a Shorewall error at startup (they always have produced warnings in iptables).
The MERGE_HOSTS variable has been removed from shorewall.conf. Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents are determined by BOTH the interfaces and hosts files when there are entries for the zone in both files.
The routestopped option in the interfaces and hosts file has been eliminated; use entries in the routestopped file instead.
The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer accepted; you must convert to using the new syntax.
The ALLOWRELATED variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
Late-arriving DNS replies are now dropped by default; there is no need for your own /etc/shorewall/common file simply to avoid logging these packets.
The firewall, functions and version files have been moved to /usr/share/shorewall.
The icmp.def file has been removed. If you include it from /etc/shorewall/icmpdef, you will need to modify that file.
If you followed the advice in FAQ #2 and call find_interface_address in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
The multi interface option is no longer supported. Shorewall will generate rules for sending packets back out the same interface that they arrived on in two cases:
There is an explicit policy for the source zone to or from the destination zone. An explicit policy names both zones and does not use the all reserved word.
There are one or more rules for traffic for the source zone to or from the destination zone including rules that use the all reserved word. Exception: if the source zone and destination zone are the same then the rule must be explicit - it must name the zone in both the SOURCE and DESTINATION columns.
Beginning in version 1.3.14, Shorewall treats entries in /etc/shorewall/masq differently. The change involves entries with an interface name in the SUBNET (second) column:
Prior to 1.3.14, Shorewall would detect the FIRST subnet on the interface (as shown by “ip addr show interface”) and would masquerade traffic from that subnet. Any other subnets that routed through eth1 needed their own entry in /etc/shorewall/masq to be masqueraded or to have SNAT applied.
Beginning with Shorewall 1.3.14, Shorewall uses the firewall's routing table to determine ALL subnets routed through the named interface. Traffic originating in ANY of those subnets is masqueraded or has SNAT applied.
You will need to make a change to your configuration if:
You have one or more entries in /etc/shorewall/masq with an interface name in the SUBNET (second) column; and
That interface connects to more than one subnetwork.
Two examples:
Example 1. Suppose that your current config is as follows:
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth0 192.168.10.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE [root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]# |
In this case, the second entry in /etc/shorewall/masq is no longer required.
Example 2. What if your current configuration is like this?
[root@gateway test]# cat /etc/shorewall/masq #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE [root@gateway test]# ip route show dev eth2 192.168.1.0/24 scope link 192.168.10.0/24 proto kernel scope link src 192.168.10.254 [root@gateway test]# |
In this case, you would want to change the entry in /etc/shorewall/masq to:
#INTERFACE SUBNET ADDRESS eth0 192.168.1.0/24 206.124.146.176 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE |
Version 1.3.14 also introduced simplified ICMP echo-request (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf is used to specify that the old (pre-1.3.14) ping handling is to be used (If the option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the old handling indefinitely so I urge current users to migrate to using the new handling as soon as possible. See the 'Ping' handling documentation for details.
If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to version 1.3.10, you will need to use the --force option:
rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm |
The functions file has moved to /usr/lib/shorewall/functions. If you have an application that uses functions from that file, your application will need to be changed to reflect this change of location.
If you have a pair of firewall systems configured for failover or if you have asymmetric routing, you will need to modify your firewall setup slightly under Shorewall versions >= 1.3.8. Beginning with version 1.3.8, you must set NEWNOTSYN=Yes in your /etc/shorewall/shorewall.conf file.
Users specifying ALLOWRELATED=No in /etc/shorewall.conf will need to include the following rules in their /etc/shorewall/icmpdef file (creating this file if necessary):
run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT |
Users having an /etc/shorewall/icmpdef file may remove the ./etc/shorewall/icmp.def command from that file since the icmp.def file is now empty.
To properly upgrade with Shorewall version 1.3.3 and later:
Be sure you have a backup -- you will need to transcribe any Shorewall configuration changes that you have made to the new configuration.
Replace the shorwall.lrp package provided on the Bering floppy with the later one. If you did not obtain the later version from Jacques's site, see additional instructions below.
Edit the /var/lib/lrpkg/root.exclude.list file and remove the /var/lib/shorewall entry if present. Then do not forget to backup root.lrp!
The .lrp that I release isn't set up for a two-interface firewall like Jacques's. You need to follow the instructions for setting up a two-interface firewall plus you also need to add the following two Bering-specific rules to /etc/shorewall/rules:
# Bering specific rules: # allow loc to fw udp/53 for dnscache to work # allow loc to fw tcp/80 for weblet to work # ACCEPT loc fw udp 53 ACCEPT loc fw tcp 80 |
If you have a pair of firewall systems configured for failover or if you have asymmetric routing, you will need to modify your firewall setup slightly under Shorewall versions 1.3.6 and 1.3.7
Create the file /etc/shorewall/newnotsyn and in it add the following rule:
# So that the connection tracking table can be rebuilt # from non-SYN packets after takeover. run_iptables -A newnotsyn -j RETURN |
Create /etc/shorewall/common (if you don't already have that file) and include the following:
#Accept Acks to rebuild connection tracking table. run_iptables -A common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT ./etc/shorewall/common.def |