diff --git a/Shorewall-docs/upgrade_issues.xml b/Shorewall-docs/upgrade_issues.xml
index ddb1c280d..eeb02a813 100644
--- a/Shorewall-docs/upgrade_issues.xml
+++ b/Shorewall-docs/upgrade_issues.xml
@@ -89,11 +89,10 @@
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
-
+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
@@ -140,9 +139,9 @@ 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
+ 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.
@@ -162,10 +161,10 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
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.
@@ -177,27 +176,25 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
interfaces and, hosts file
contents/etc/shorewall/zones
-z1 Zone1 The first Zone
-z2 Zone2 The second Zone
+z1 Zone1 The first Zone
+z2 Zone2 The second Zone
/etc/shorewall/interfaces
-z2 eth1 192.168.1.255
+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>
+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>/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.
+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.
@@ -222,16 +219,16 @@ z2 z1 NONE
Shorewall >=1.4.0 requires the iproute
- package ('ip' utility).
+ 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
- option of rpm (rpm -Uvh --nodeps
+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
your_shorewall_rpm.rpm).
@@ -318,8 +315,7 @@ error: failed dependencies:iproute is needed by shorewall-1.4.0-1
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
+[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
@@ -328,12 +324,10 @@ eth0 192.168.10.0/24 206.124.146.176
[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
+[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
@@ -341,21 +335,20 @@ eth0 eth2 206.124.146.176
[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
+[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
+#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.
+ Ping handling documentation for details.
@@ -365,9 +358,7 @@ eth0 192.168.1.0/24 206.124.146.176
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
-
+ option: rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
@@ -411,13 +402,12 @@ rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
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 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
+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.
@@ -444,14 +434,12 @@ run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
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:
+ # 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
-
+ACCEPT loc fw tcp 80
@@ -467,19 +455,15 @@ ACCEPT loc fw tcp 80
Create the file /etc/shorewall/newnotsyn
and in it add the following rule:
-
-# So that the connection tracking table can be rebuilt
+ # 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
+run_iptables -A newnotsyn -j RETURNCreate
+ /etc/shorewall/common
(if you don't already have that file) and include the following:
-
-#Accept Acks to rebuild connection tracking table.
+ #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
-
+./etc/shorewall/common.def
@@ -490,17 +474,10 @@ run_iptables -A common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT
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
-
+ 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
@@ -519,4 +496,4 @@ REDIRECT loc 3128 tcp 80
-
+
\ No newline at end of file