diff --git a/Shorewall-docs2/Install.xml b/Shorewall-docs2/Install.xml index ed9c027a4..969aca3d7 100644 --- a/Shorewall-docs2/Install.xml +++ b/Shorewall-docs2/Install.xml @@ -15,7 +15,7 @@ - 2004-10-27 + 2004-10-31 2001 @@ -523,6 +523,10 @@ tar -xzvf /mnt/package2.lrp instructions! :-) + + For information on other LEAF/Bering upgrade tools, check out this + article by Alex Rhomberg.
diff --git a/Shorewall-docs2/upgrade_issues.xml b/Shorewall-docs2/upgrade_issues.xml index 9732c79a4..d2771fe26 100644 --- a/Shorewall-docs2/upgrade_issues.xml +++ b/Shorewall-docs2/upgrade_issues.xml @@ -30,7 +30,8 @@ 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. + GNU Free Documentation + License. @@ -41,10 +42,10 @@ 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. + 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: @@ -61,20 +62,127 @@
- Version >= 2.0.2 RC1 + Version >= 2.2.0 Beta 1 + + + + + + Shorewall configuration files except shorewall.conf are now + empty (they contain only comments). If you wish to retain the defaults + in any of the following files, you should copy these files before + upgrading them then restore them after the upgrade: + + + /etc/shorewall/zones + + /etc/shorewall/policy + + /etc/shorewall/tos + + + + + The following builtin actions have been removed and have been + replaced by the new action logging implementation described in the new + features below. + + + logNotSyn + + rLogNotSyn + + dLogNotSyn + + + + + If shorewall.conf is upgraded to the latest version, it needs + to be modified to set STARTUP_ENABLED=Yes. + + + + The Leaf/Bering version of Shorewall was previously + named: + + + shorwall-<version>.lrp + + + Beginning with 2.1, that file will now be named: + + + shorewall-lrp-<version>.tgz + + + Simply rename that file to 'shorwall.lrp' when installing it on + your LEAF/Bering system. + + + + The ORIGINAL DEST column of the /etc/shorewall/rules file may no + longer contain a second (SNAT) address. You must use an entry in + /etc/shorewall/masq instead. + + Example from Shorewall FAQ #1: + +
+ Prior to Shorewall 2.1: + + /etc/shorewall/interfaces + + #ZONE INTERFACE BROADCAST OPTIONS +loc eth1 detect routeback + + /etc/shorewall/rules + + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL +# PORT DEST +DNAT loc loc:192.168.1.12 tcp 80 - 130.252.100.69:192.168.1.254 + + Shorewall 2.1 and Later: + + /etc/shorewall/interfaces + + #ZONE INTERFACE BROADCAST OPTIONS +loc eth1 detect routeback + + /etc/shorewall/masq: + + #INTERFACE SUBNETS ADDRESS PROTO PORT(S) +eth1 eth1 192.168.1.254 tcp 80 + + /etc/shorewall/rules: + + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL +# PORT DEST +DNAT loc loc:192.168.1.12 tcp 80 - 130.252.100.69 +
+ + + + The 'logunclean' and 'dropunclean' options that were deprecated + in Shorewall 2.0 have now been removed completely. + + +
+ +
+ Version >= 2.0.2 RC1 If you are upgrading from Shorewall 1.4.x and you have commands in your /etc/shorewall/common file that are not directly related to the common chain - then you will want to move those commands to /etc/shorewall/initdone. + then you will want to move those commands to + /etc/shorewall/initdone.
- Version >= 2.0.2 Beta 1 + Version >= 2.0.2 Beta 1 @@ -85,10 +193,11 @@ If your extension scripts are executing commands other than iptables then those commands must also be written - to the restore file (a temporary file in /var/lib/shorewall - that is renamed /var/lib/shorewall/restore-base - at the completeion of the /sbin/shorewall - command). The following functions should be of help: + to the restore file (a temporary file in /var/lib/shorewall that is renamed + /var/lib/shorewall/restore-base at the + completeion of the /sbin/shorewall command). The + following functions should be of help: @@ -97,14 +206,14 @@ Example: save_command echo Operation Complete - That command would simply write "echo Operation - Complete" to the restore file. + That command would simply write "echo Operation Complete" to + the restore file. run_and_save_command() -- saves the passed command to the restore file then executes it. The return value is the exit status - of the command. Example: run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all" + of the command. Example: run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all" Note that as in this example, when the command involves file redirection then the entire command must be enclosed in quotes. @@ -113,54 +222,55 @@ ensure_and_save_command() -- runs the passed command. If the - command fails, the firewall is restored to it's prior saved - state and the operation is terminated. If the command succeeds, - the command is written to the restore file + command fails, the firewall is restored to it's prior saved state + and the operation is terminated. If the command succeeds, the + command is written to the restore file - Dynamic Zone support. - If you don't need to use the - shorewall add and shorewall delete - commands, you should set DYNAMIC_ZONES=No in /etc/shorewall/shorewall.conf. + Dynamic Zone support. - If you don't need to use the + shorewall add and shorewall + delete commands, you should set DYNAMIC_ZONES=No in + /etc/shorewall/shorewall.conf.
- Version >= 2.0.1 + Version >= 2.0.1 - The function of 'norfc1918' is now split between that - option and a new 'nobogons' option. The rfc1918 file released - with Shorewall now contains entries for only those three address - ranges reserved by RFC 1918. A 'nobogons' interface option has - been added which handles bogon source addresses (those which are - reserved by the IANA, those reserved for DHCP auto-configuration and - the class C test-net reserved for testing and documentation examples). - This will allow users to perform RFC 1918 filtering without having to - deal with out of date data from IANA. Those who are willing to update - their /usr/share/shorewall/bogons file regularly - can specify the 'nobogons' option in addition to - 'norfc1918'. The level at which bogon packets are logged is - specified in the new BOGON_LOG_LEVEL variable in shorewall.conf. If - that option is not specified or is specified as empty (e.g, - BOGON_LOG_LEVEL="") then bogon packets whose TARGET is - 'logdrop' in /usr/share/shorewall/bogons - are logged at the 'info' level. + The function of 'norfc1918' is now split between that option and + a new 'nobogons' option. The rfc1918 file released with Shorewall now + contains entries for only those three address ranges reserved by RFC + 1918. A 'nobogons' interface option has been added which handles bogon + source addresses (those which are reserved by the IANA, those reserved + for DHCP auto-configuration and the class C test-net reserved for + testing and documentation examples). This will allow users to perform + RFC 1918 filtering without having to deal with out of date data from + IANA. Those who are willing to update their + /usr/share/shorewall/bogons file regularly can + specify the 'nobogons' option in addition to 'norfc1918'. The level at + which bogon packets are logged is specified in the new BOGON_LOG_LEVEL + variable in shorewall.conf. If that option is not specified or is + specified as empty (e.g, BOGON_LOG_LEVEL="") then bogon packets whose + TARGET is 'logdrop' in + /usr/share/shorewall/bogons are logged at the + 'info' level.
- VERSION >= 2.0.0-Beta1 + VERSION >= 2.0.0-Beta1 - The 'dropunclean' and 'logunclean' interface - options are no longer supported. If either option is specified in + 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. @@ -169,18 +279,19 @@ 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. + 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. + 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: + The following files don't exist in Shorewall 2.0: /etc/shorewall/common.def @@ -190,13 +301,14 @@ /etc/shorewall/icmpdef /etc/shorewall/action.template (moved - to /usr/share/shorewall/action.template) + 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). + 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 @@ -212,28 +324,29 @@ 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. + 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. + url="User_defined_Actions.html">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. + 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. + 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. @@ -241,64 +354,69 @@ now labeled USER/GROUP and may contain: - [!]<user number>[:] + [!]<user number>[:] - [!]<user name>[:] + [!]<user name>[:] - [!]:<group number> + [!]:<group number> - [!]:<group name> + [!]:<group name> - [!]<user number>:<group - number> + [!]<user + number>:<group + number> - [!]<user name>:<group - number> + [!]<user + name>:<group + number> - [!]<user inumber>:<group - name> + [!]<user + inumber>:<group + name> - [!]<user name>:<group - name> + [!]<user + name>:<group name> - If your kernel has IPV6 support (recent SuSe - for example), and you don't use IPV6 then you will probably want - to set DISABLE_IPV6=Yes in /etc/shorewall/shorewall.conf. + If your kernel has IPV6 support (recent + SuSe for example), and you don't use IPV6 then + you will probably want to set DISABLE_IPV6=Yes in /etc/shorewall/shorewall.conf. You must have ipv6tables installed.
- Version >= 1.4.8 + Version >= 1.4.8 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 + 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 + /etc/shorewall/interfaces entries.
- Version >= 1.4.6 + Version >= 1.4.6 - The NAT_ENABLED, MANGLE_ENABLED - and MULTIPORT options have been removed from - shorewall.conf. These capabilities are now - automatically detected by Shorewall. + The NAT_ENABLED, + MANGLE_ENABLED and MULTIPORT + options have been removed from shorewall.conf. + These capabilities are now automatically detected by Shorewall. @@ -314,39 +432,48 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
- Version >= 1.4.4 + Version >= 1.4.4 - If you are upgrading from 1.4.3 and have set the LOGMARKER - variable in /etc/shorewall/shorewall.conf, + 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. + appropriately and remove your setting of + LOGMARKER.
Version 1.4.4 If you have zone names that are 5 characters long, you may - experience problems starting Shorewall because the - in a logging rule is too long. Upgrade to Version 1.4.4a to fix this - problem. + experience problems starting Shorewall because the + in a logging rule is too long. Upgrade to + Version 1.4.4a to fix this problem.
- Version >= 1.4.2 + Version >= 1.4.2 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: In FAQ - #2When running Squid - as a transparent proxy in your local zone. - If you have either of these cases, you will want to review the current - documentation and change your configuration accordingly. + can occur: + + In FAQ #2 + + + + When running + Squid as a transparent proxy in your + local zone. + + If you have either of these cases, you will want to + review the current documentation and change your configuration + accordingly.
- Version >= 1.4.1 + Version >= 1.4.1 @@ -355,11 +482,10 @@ zone eth1:192.168.1.0/24,192.168.2.0/24 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. + 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. @@ -371,26 +497,29 @@ zone eth1:192.168.1.0/24,192.168.2.0/24 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 + 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. + 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. The <filename>zones</filename>, - <filename>interfaces</filename> and, <filename>hosts</filename> file - contents + don't want Shorewall to set up any infrastructure to handle traffic + between them. + The <filename>zones</filename>, + <filename>interfaces</filename> and, <filename>hosts</filename> + file contents + + /etc/shorewall/zones z1 Zone1 The first Zone z2 Zone2 The second Zone @@ -400,17 +529,21 @@ 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: The contents of - <filename>policy</filename> + + 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: + The contents of <filename>policy</filename> + + /etc/shorewall/policy z1 z2 NONE z2 z1 NONE - Note that NONE policies are generally used in - pairs unless there is asymetric routing where only the traffic on one + + 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. @@ -423,21 +556,21 @@ z2 z1 NONE 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. + 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.
- Version >= 1.4.0 + Version >= 1.4.0 - Shorewall >=1.4.0 requires the iproute - package ('ip' utility). + Shorewall >=1.4.0 requires the iproute + package ('ip' utility). @@ -445,46 +578,89 @@ z2 z1 NONE 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 - option of rpm (rpm -Uvh --nodeps + This may be worked around by using the + 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. + 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. + +
@@ -495,242 +671,24 @@ error: failed dependencies:iproute is needed by shorewall-1.4.0-1 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. - - -
+ mark="hollow"> + + 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. + -
- Version >= 1.3.14 - - 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; - andThat interface connects to more than - one subnetwork. Two examples: 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. 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. -
- -
- Version 1.3.10 - - - - 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 - option: -rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm - - - -
- -
- Version >= 1.3.9 - - - - 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. - - -
- -
- Version >= 1.3.8 - - - - 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. - - -
- -
- Version >= 1.3.7 - - - - 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. - - -
- -
- Upgrading Bering to Shorewall >= 1.3.3 - - - - 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 - - - -
- -
- Version 1.3.6 and 1.3.7 - - - - 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 - - - -
- -
- Versions >= 1.3.5 - - - - Some forms of pre-1.3.0 rules file syntax are no longer - supported. -ACCEPT net loc:192.168.1.12:22 tcp 11111 - all - Must be replaced with: - -DNAT net loc:192.168.1.12:22 tcp 11111 - -ACCEPT loc fw::3128 tcp 80 - all - Must be replaced with: - -REDIRECT loc 3128 tcp 80 - - - -
- -
- Version >= 1.3.2 - - - - The functions and versions files together with the firewall symbolic link have moved from - /etc/shorewall to /var/lib/shorewall. If you have - applications that access these files, those applications should be - modified accordingly. + + 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. + +