diff --git a/Shorewall-docs/upgrade_issues.htm b/Shorewall-docs/upgrade_issues.htm deleted file mode 100755 index 32cf343ff..000000000 --- a/Shorewall-docs/upgrade_issues.htm +++ /dev/null @@ -1,378 +0,0 @@ - - - - - Upgrade Issues - - - - - -

Upgrade Issues
-

-

For upgrade instructions see the Install/Upgrade -page.
-

-

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.
-

-

-

Version >= 1.4.8

- -

Version >= 1.4.6

- -

Version >= 1.4.4

-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
-
-

Version 1.4.4
-

-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..
-

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:
-
    -
  1. In FAQ #2.
    2. -
  2. When running Squid as a -transparent proxy in your local zone.
    3. -
-If you have either of these cases, you will want to review the current -documentation and change your configuration accordingly.
-

Version >= 1.4.1

- -
-
    -
  1. 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.
    2. -
  2. 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.
    3. -
  3. 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.
    -
    4. -
-
- -
Example:
-
- 
/etc/shorewall/zones

z1	Zone1	The first Zone
z2	Zone2	The secont 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:
-
- 
/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 direction flows through -the firewall and you are using a NONE polciy in the other -direction. 
-

Version 1.4.1
-

- -

Version >= 1.4.0

-IMPORTANT: Shorewall >=1.4.0 requires the iproute -package ('ip' utility).
-
-Note: 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 <shorewall rpm>).
-
-If you are upgrading from a version < 1.4.0, then:
- - -

Version 1.4.0

- -
- - -
-

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:
- -You will need to make a change to your configuration -if:
-
    -
  1. You have one or more entries in /etc/shorewall/masq with an -interface name in the SUBNET (second) column; and
    2. -
  2. That interface connects to more than one subnetwork.
    3. -
-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.
-

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 '--force' -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:

-
    -
  1. Be sure you have a backup -- you will need to transcribe any -Shorewall configuration changes that you have made to the new -configuration.
    2. -
  2. 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.
    3. -
  3. 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 !
    4. -
-

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

-
    -
  1. -

    Create the file /etc/shorewall/newnotsyn and in it -add the following rule
    -
    - run_iptables -A -newnotsyn -j RETURN # So that the connection tracking -table can be rebuilt
    -                                    -# from non-SYN packets after takeover.
    - 

    -
    2. -
  2. -

    Create /etc/shorewall/common (if you don't already -have that file) and include the following:
    -
    - run_iptables -A -common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT -#Accept Acks to rebuild connection
    -                                                                    -#tracking table.
    -. /etc/shorewall/common.def

    -
    3. -
-

Versions >= 1.3.5

-

Some forms of pre-1.3.0 rules file syntax are no longer -supported.

-

Example 1:

-
-
	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
-
-
-

Example 2:

-
-
-
	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.

-

Last updated 10/30/2003 - Tom -Eastep

-

Copyright -© 2001, 2002, 2003 Thomas M. Eastep
-

- -