From 59aad1c59661b75000a51a311d0c85e342c19c10 Mon Sep 17 00:00:00 2001 From: mhnoyes Date: Sun, 28 Dec 2003 19:36:40 +0000 Subject: [PATCH] fixed quotes git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1012 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/upgrade_issues.xml | 139 +++++++++++++----------------- 1 file changed, 58 insertions(+), 81 deletions(-) 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