diff --git a/LrpN/etc/shorewall/masq b/LrpN/etc/shorewall/masq index c4a1cdd5e..0074c901a 100644 --- a/LrpN/etc/shorewall/masq +++ b/LrpN/etc/shorewall/masq @@ -111,18 +111,6 @@ # your kernel and iptables must include policy # match support. # -# Yes -- Only packets that will be encrypted using -# an ipsec policy will have their source -# address changed. -# -# No -- Only packets that will not be encrypted -# using an ipsec policy will have their -# source address changed. -# -# - or empty is the same as No providing that -# your kernel and iptables contain policy match -# support. -# # Comma-separated list of options from the following. # Only packets that will be encrypted via an SA that # matches these options will have their source address diff --git a/LrpN/etc/shorewall/rules b/LrpN/etc/shorewall/rules index 4cd3a4373..8f7e0aeaf 100755 --- a/LrpN/etc/shorewall/rules +++ b/LrpN/etc/shorewall/rules @@ -72,7 +72,7 @@ # DNAT:debug). This causes the packet to be # logged at the specified level. # -# If the ACTION names an action devined in +# If the ACTION names an action defined in # /etc/shorewall/actions or in # /usr/share/shorewall/actions.std then: # diff --git a/LrpN/usr/share/shorewall/action.AllowNNTP b/LrpN/usr/share/shorewall/action.AllowNNTP index 6b6967ddf..a5d68b49e 100644 --- a/LrpN/usr/share/shorewall/action.AllowNNTP +++ b/LrpN/usr/share/shorewall/action.AllowNNTP @@ -1,10 +1,11 @@ # # Shorewall 2.2 /usr/share/shorewall/action.AllowNNTP # -# This action accepts NNTP traffic (Usenet). +# This action accepts NNTP traffic (Usenet) and encrypted NNTP (NNTPS) # ###################################################################################### #TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/ # PORT PORT(S) LIMIT GROUP ACCEPT - - tcp 119 +ACCEPT - - tcp 563 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE diff --git a/LrpN/usr/share/shorewall/bogons b/LrpN/usr/share/shorewall/bogons index 7b96cefde..43c37b1f2 100644 --- a/LrpN/usr/share/shorewall/bogons +++ b/LrpN/usr/share/shorewall/bogons @@ -1,5 +1,5 @@ # -# Shorewall 2.0-- Bogons File +# Shorewall 2.2-- Bogons File # # /etc/shorewall/bogons # @@ -48,7 +48,6 @@ 42.0.0.0/8 logdrop # Reserved 49.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98 50.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98 -58.0.0.0/7 logdrop # Reserved 73.0.0.0/8 logdrop # Reserved 74.0.0.0/7 logdrop # Reserved 76.0.0.0/6 logdrop # Reserved diff --git a/LrpN/usr/share/shorewall/firewall b/LrpN/usr/share/shorewall/firewall index 612ac167d..1ae200063 100755 --- a/LrpN/usr/share/shorewall/firewall +++ b/LrpN/usr/share/shorewall/firewall @@ -1749,6 +1749,7 @@ setup_tunnels() # $1 = name of tunnels file # Process the ipsec file # setup_ipsec() { + local zone # # Add a --set-mss rule to the passed chain # @@ -6642,18 +6643,21 @@ add_to_zone() # $1 = [:] $2 = zone # validate_interfaces_file # + # Validate IPSec File + # + f=$(find_file ipsec) + + if [ -f $f ]; then + progress_message "Processing $f..." + setup_ipsec $f + fi + # # Validate Zone # zone=$2 validate_zone $zone || startup_error "Unknown zone: $zone" - f=$(find_file ipsec) - if [ -f $f ]; then - progress_message "Processing $f..." - setup_ipsec $f - fi - [ "$zone" = $FW ] && startup_error "Can't add $1 to firewall zone" eval is_ipsec=\$${zone}_is_ipsec diff --git a/LrpN/usr/share/shorewall/version b/LrpN/usr/share/shorewall/version index 16b54a05e..6af336bdb 100644 --- a/LrpN/usr/share/shorewall/version +++ b/LrpN/usr/share/shorewall/version @@ -1 +1 @@ -2.2.0-Beta3 +2.2.0-Beta4 diff --git a/Shorewall-docs2/Documentation.xml b/Shorewall-docs2/Documentation.xml index b66d03351..f51ee5877 100644 --- a/Shorewall-docs2/Documentation.xml +++ b/Shorewall-docs2/Documentation.xml @@ -5,7 +5,7 @@ - Shorewall 2.0 Reference + Shorewall 2.x Reference @@ -15,7 +15,7 @@ - 2004-10-25 + 2004-11-18 2001-2004 @@ -181,6 +181,16 @@ + + ipsec + + + a parameter file installed in /etc/shorewall and used to describe + ipsec policies associated with zones. + + + maclist @@ -1625,7 +1635,11 @@ ACCEPT:info - - tc refers to a connection request from any host in the - specified subnet (example net:155.186.235.0/24). + specified subnet (example net:155.186.235.0/24). Beginning + with Shorewall 2.1.0, IP address ranges of the form + <first address>-<last + address> may be specified. This requires that + your kernel and iptables have iprange match support. @@ -1674,7 +1688,7 @@ ACCEPT:info - - tc - Unlike in the SOURCE column, a range of IP addresses may be + Like in the SOURCE column, a range of IP addresses may be specified in the DEST column as <first address>-<last address>. When the ACTION is DNAT or DNAT-, connections will be assigned to @@ -2566,7 +2580,7 @@ eth0 eth1 206.124.146.176 Example: Using the default LOGFORMAT, the log prefix for - logging from the nat table's PREROUTING chain is: + logging from the nat table's PREROUTING chain is: Shorewall:nat:PREROUTING @@ -2934,7 +2948,7 @@ eth0 eth1 206.124.146.176 enable martian logging for all interfaces, you may still enable it for individual interfaces using the logmartians interface option in /etc/shorewall/interfaces. + linkend="Interfaces">/etc/shorewall/interfaces. diff --git a/Shorewall-docs2/Documentation_Index.xml b/Shorewall-docs2/Documentation_Index.xml index 6a0223d6e..c51662133 100644 --- a/Shorewall-docs2/Documentation_Index.xml +++ b/Shorewall-docs2/Documentation_Index.xml @@ -15,7 +15,7 @@ - 2004-11-03 + 2004-11-18 2001-2004 @@ -23,7 +23,7 @@ Thomas M. Eastep - 2.2.0 Beta 2 + 2.2.0 Beta 4 Permission is granted to copy, distribute and/or modify this @@ -275,6 +275,10 @@ netmap + + + ipsec + diff --git a/Shorewall-docs2/FAQ.xml b/Shorewall-docs2/FAQ.xml index 3f92b63c9..13afb122f 100644 --- a/Shorewall-docs2/FAQ.xml +++ b/Shorewall-docs2/FAQ.xml @@ -17,7 +17,7 @@ - 2004-11-05 + 2004-11-18 2001-2004 @@ -1966,12 +1966,53 @@ REJECT fw net:216.239.39.99 allGiven that then be accurately parsed and decisions can be made based on the result. + +
+ (FAQ 42) How can I tell which features my kernel and iptables + support? + + Answer: At a root prompt, enter the command shorewall + check. There is a section near the top of the resulting output + that gives you a synopsis of your kernel/iptables capabilities. + + gateway:/etc/shorewall # shorewall check +Loading /usr/share/shorewall/functions... +Processing /etc/shorewall/params ... +Processing /etc/shorewall/shorewall.conf... +Loading Modules... + +Notice: The 'check' command is unsupported and problem + reports complaining about errors that it didn't catch + will not be accepted + +Shorewall has detected the following iptables/netfilter capabilities: + NAT: Available + Packet Mangling: Available + Multi-port Match: Available + Connection Tracking Match: Available + Packet Type Match: Not available + Policy Match: Available + Physdev Match: Available + IP range Match: Available +Verifying Configuration... +... +
Revision History + + 1.38 + + 2004-11-18 + + TE + + Added FAQ 42. + + 1.37 diff --git a/Shorewall-docs2/Introduction.xml b/Shorewall-docs2/Introduction.xml index adfa3d4d5..7461f6ef2 100644 --- a/Shorewall-docs2/Introduction.xml +++ b/Shorewall-docs2/Introduction.xml @@ -13,7 +13,7 @@ Eastep - 2004-07-10 + 2004-11-18 2003-2004 @@ -27,14 +27,15 @@ 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.
Introduction - The information in this document applies only to 2.0.x releases of + The information in this document applies only to 2.x releases of Shorewall.
@@ -43,7 +44,8 @@ Netfilter - the - packet filter facility built into the 2.4 and later Linux kernels. + packet filter facility built into the 2.4 and later Linux + kernels. @@ -65,19 +67,19 @@
What is Shorewall? - The Shoreline Firewall, more commonly known as Shorewall, - is high-level tool for configuring Netfilter. You describe your - firewall/gateway requirements using entries in a set of configuration - files. Shorewall reads those configuration files and with the help of - the iptables utility, Shorewall configures Netfilter to match your - requirements. Shorewall can be used on a dedicated firewall system, a - multi-function gateway/router/server or on a standalone GNU/Linux - system. Shorewall does not use Netfilter's ipchains compatibility - mode and can thus take advantage of Netfilter's connection state - tracking capabilities. + The Shoreline Firewall, more commonly known as + Shorewall, is high-level tool for configuring Netfilter. + You describe your firewall/gateway requirements using entries in a set + of configuration files. Shorewall reads those configuration files and + with the help of the iptables utility, Shorewall configures Netfilter to + match your requirements. Shorewall can be used on a dedicated firewall + system, a multi-function gateway/router/server or on a standalone + GNU/Linux system. Shorewall does not use Netfilter's ipchains + compatibility mode and can thus take advantage of Netfilter's connection + state tracking capabilities. Shorewall is not a daemon. Once Shorewall has configured - Netfilter, it's job is complete and there is no Shorewall + Netfilter, it's job is complete and there is no Shorewall process left running in your system. The /sbin/shorewall program can be used at any time to monitor the Netfilter firewall. @@ -92,54 +94,109 @@ setups, you will only need to deal with a few of them. Shorewall views the network where it is running as being composed of - a set of zones. In the three-interface - sample configuration for example, the following zone names are - used: NameDescriptionnetThe InternetlocYour Local - NetworkdmzDemilitarized ZoneZones - are defined in the zones. In the three-interface sample configuration for + example, the following zone names are used: + + + + Name + + Description + + + + + + net + + The Internet + + + + loc + + Your Local Network + + + + dmz + + Demilitarized Zone + + + + Zones are defined in the /etc/shorewall/zones file. Shorewall also recognizes the firewall system as its own zone - by - default, the firewall itself is known as fw. + default, the firewall itself is known as fw. Rules about what traffic to allow and what traffic to deny are - expressed in terms of zones. You - express your default policy for connections from one zone to another zone - in the /etc/shorewall/policy - file. The choices for policy are:ACCEPT - - Accept the connection.DROP - Ignore - the connection request.REJECT - Return - an appropriate error to the connection request.Connection - request logging may be specified as part of a policy and it is - conventional to log DROP and REJECT policies.You - define exceptions to those default policies in the /etc/shorewall/rules - file.You only need concern yourself with - connection requests. You don't need to define rules for how traffic - that is part of an established connection is handled and in most cases you - don't have to worry about how related connections are handled (ICMP - error packets and related TCP connection requests - such as used by FTP).For each - connection request entering the firewall, the request is first checked - against the /etc/shorewall/rules - file. If no rule in that file matches the connection request then the - first policy in /etc/shorewall/policy - that matches the request is applied. If there is a common action defined - for the policy in /etc/shorewall/actions (or /usr/share/shorewall/actions.std) - then that action is invoked before the policy is enforces. In the standard - Shorewall distribution, the DROP policy has a common action called - Drop and the REJECT policy has a common - action called Reject. Common actions are - used primarily to discard + expressed in terms of zones. + + You express your default policy for connections from one zone + to another zone in the /etc/shorewall/policy + file. The basic choices for policy are: - The /etc/shorewall/policy + + + ACCEPT - Accept the connection. + + + + DROP - Ignore the connection request. + + + + REJECT - Return an appropriate error to the connection + request. + + + + Connection request logging may be specified as part of a + policy and it is conventional to log DROP and REJECT + policies. + + + + You define exceptions to these default policies in the /etc/shorewall/rules + file. + + + + You only need concern yourself with connection requests. You + don't need to define rules for how traffic that is part of an + established connection is handled and in most cases you don't have + to worry about how related connections are handled (ICMP error + packets and related TCP connection requests + such as used by FTP). + + For each connection request entering the firewall, the + request is first checked against the /etc/shorewall/rules + file. If no rule in that file matches the connection request then the + first policy in /etc/shorewall/policy + that matches the request is applied. If there is a common action defined + for the policy in /etc/shorewall/actions (or + /usr/share/shorewall/actions.std) then that action is + invoked before the policy is enforces. In the standard Shorewall + distribution, the DROP policy has a common action called Drop and the REJECT policy has a common action + called Reject. Common actions are used + primarily to discard + + The /etc/shorewall/policy file included with the three-interface sample has the following policies: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT @@ -149,18 +206,34 @@ all all REJECT infoIn the three-interface firewall system to have full access to servers on the internet, uncomment that line. #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST fw net ACCEPT The above policy will: - Allow all connection requests from your - local network to the internetDrop - (ignore) all connection requests from the internet to your firewall or - local network; these ignored connection requests will be logged using the - info syslog priority (log level).Optionally - accept all connection requests from the firewall to the internet (if you - uncomment the additional policy)reject - all other connection requests; these rejected connection requests will be - logged using the info syslog priority (log level). + + + Allow all connection requests from your local network to the + internet + + + + Drop (ignore) all connection requests from the internet to + your firewall or local network; these ignored connection requests + will be logged using the info syslog priority + (log level). + + + + Optionally accept all connection requests from the firewall to + the internet (if you uncomment the additional policy) + + + + reject all other connection requests; these rejected + connection requests will be logged using the + info syslog priority (log level). + + The simplest way to define a zone is to associate the zone with a - network interface using the /etc/shorewall/interfaces + network interface using the /etc/shorewall/interfaces file. In the three-interface sample, the three zones are defined using that file as follows: @@ -194,16 +267,16 @@ ACCEPT net fw tcp 22 The QuickStart guildes provide links to download pre-populated files for use - in common setups and the Shorewall - Setup Guide shows you examples for use with other more complex - setups. + in common setups and the Shorewall Setup Guide shows + you examples for use with other more complex setups. - To keep your firewall log - from filling up with useless noise, Shorewall provides common actions that silently - discard or reject such noise before it can be logged. As with + To keep your firewall + log from filling up with useless noise, Shorewall provides + common actions that + silently discard or reject such noise before it can be logged. As with everything in Shorewall, you can alter the behavior of these common actions (or do away with them entirely) as you see fit. @@ -214,9 +287,10 @@ ACCEPT net fw tcp 22 License This program is free software; you can redistribute it and/or modify - it under the terms of Version - 2 of the GNU General Public License as published by the Free - Software Foundation. + it under the terms of Version 2 of the GNU General + Public License as published by the Free Software + Foundation. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY diff --git a/Shorewall-docs2/ProxyARP.xml b/Shorewall-docs2/ProxyARP.xml index 6180d69e9..2a98354cd 100644 --- a/Shorewall-docs2/ProxyARP.xml +++ b/Shorewall-docs2/ProxyARP.xml @@ -15,7 +15,7 @@ - 2004-08-10 + 2004-11-16 2001-2004 @@ -29,7 +29,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. @@ -37,9 +38,9 @@ one network appear to be logically part of a different physical network connected to the same router/firewall. Typically it allows us to hide a machine with a public IP address on a private network behind a router, and - still have the machine appear to be on the public network "in front - of" the router. The router "proxys" ARP requests and all network - traffic to and from the hidden machine to make this fiction possible. + still have the machine appear to be on the public network "in front of" the + router. The router "proxys" ARP requests and all network traffic to and from + the hidden machine to make this fiction possible. Consider a router with two interface cards, one connected to a public network PUBNET and one connected to a private network PRIVNET. We want to @@ -49,16 +50,16 @@ behind the router. By enabling proxy ARP on the router, any machine on the PUBNET network - that issues an ARP "who has" request for the server's MAC - address will get a proxy ARP reply from the router containing the - router's MAC address. This tells machines on the PUBNET network that - they should be sending packets destined for the server via the router. The - router forwards the packets from the machines on the PUBNET network to the - server on the PRIVNET network. + that issues an ARP "who has" request for the server's MAC address will get a + proxy ARP reply from the router containing the router's MAC address. This + tells machines on the PUBNET network that they should be sending packets + destined for the server via the router. The router forwards the packets from + the machines on the PUBNET network to the server on the PRIVNET + network. - Similarly, when the server on the PRIVNET network issues a "who - has" request for any machines on the PUBNET network, the router provides - its own MAC address via proxy ARP. This tells the server to send packets for + Similarly, when the server on the PRIVNET network issues a "who has" + request for any machines on the PUBNET network, the router provides its own + MAC address via proxy ARP. This tells the server to send packets for machines on the PUBNET network via the router. The router forwards the packets from the server on the PRIVNET network to the machines on the PUBNET network. @@ -71,7 +72,8 @@ hidden behind the router. Before you try to use this technique, I strongly recommend that you - read the Shorewall Setup Guide. + read the Shorewall Setup + Guide.
Example @@ -92,22 +94,22 @@ Be sure that the internal systems (130.242.100.18 and 130.252.100.19 in the above example) are not included in any specification in - /etc/shorewall/masq or /etc/shorewall/nat. - + /etc/shorewall/masq or + /etc/shorewall/nat. - I've used an RFC1918 IP address for eth1 - that IP address is + I've used an RFC1918 IP address for eth1 - that IP address is largely irrelevant (see below). The lower systems (130.252.100.18 and 130.252.100.19) should have their subnet mask and default gateway configured exactly the same way that - the Firewall system's eth0 is configured. In other words, they should - be configured just like they would be if they were parallel to the - firewall rather than behind it. + the Firewall system's eth0 is configured. In other words, they should be + configured just like they would be if they were parallel to the firewall + rather than behind it. - Do not add the Proxy ARP'ed address(es) (130.252.100.18 and + Do not add the Proxy ARP'ed address(es) (130.252.100.18 and 130.252.100.19 in the above example) to the external interface (eth0 in this example) of the firewall. @@ -132,22 +134,45 @@ url="myfiles.htm">that I take with my DMZ. - Your distribution's network configuration GUI may not be - capable of configuring a device in this way. It may complain about the - duplicate address or it may configure the address incorrectly. Here is - what the above configuration should look like when viewed using - ip (the part of the output that is in bold text is relevant): + Your distribution's network configuration GUI may not be capable + of configuring a device in this way. It may complain about the duplicate + address or it may configure the address incorrectly. Here is what the + above configuration should look like when viewed using + ip (the line "inet 130.252.100.17/32 scope global + eth1" is the most important): gateway:~# ip addr ls eth1 -3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 +3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:a0:cc:d1:db:12 brd ff:ff:ff:ff:ff:ff inet 130.252.100.17/32 scope global eth1 gateway:~# - Note in particular that there is no broadcast address. Here is how I configure a device in this - way under Debian. + Note in particular that there is no broadcast address. Here is an + ifcfg-eth-id-00:a0:cc:d1:db:12 file from SuSE that + produces this result (Note: SuSE ties the configuration file to the card + by embedding the card's MAC address in the file name): + + BOOTPROTO='static' +BROADCAST='130.252.100.17' +IPADDR='130.252.100.17' +MTU='' +NETMASK='255.255.255.255' +NETWORK='130.252.100.17' +REMOTE_IPADDR='' +STARTMODE='onboot' +UNIQUE='8otl.IPwRm6bNMRD' +_nm_name='bus-pci-0000:00:04.0' + + Here is an excerpt from a Debian /etc/shorewall/interfaces file + that does the same thing: + + ... +auto eth1 +iface eth1 inet static + address 130.252.100.17 + netmask 255.255.255.255 + broadcast 0.0.0.0 +...
@@ -163,11 +188,13 @@ gateway:~# A reading of TCP/IP Illustrated, Vol 1 by - Stevens revealsCourtesy of Bradey Honsinger - that a gratuitous ARP packet should cause the ISP's - router to refresh their ARP cache (section 4.7). A gratuitous ARP is - simply a host requesting the MAC address for its own IP; in addition - to ensuring that the IP address isn't a duplicate... + Stevens reveals + Courtesy of Bradey Honsinger + that a gratuitous ARP packet should cause + the ISP's router to refresh their ARP cache (section 4.7). A + gratuitous ARP is simply a host requesting the MAC address for its own + IP; in addition to ensuring that the IP address isn't a + duplicate...
if the host sending the gratuitous ARP has just changed its @@ -179,15 +206,16 @@ gateway:~# Which is, of course, exactly what you want to do when you switch a host from being exposed to the Internet to behind Shorewall using proxy ARP (or one-to-one NAT for that matter). Happily enough, recent - versions of Redhat's iputils package include arping, + versions of Redhat's iputils package include arping, whose -U flag does just that: - arping -U -I <net if> <newly proxied IP> + arping -U -I <net if> <newly proxied IP> arping -U -I eth0 66.58.99.83 # for example Stevens goes on to mention that not all systems respond - correctly to gratuitous ARPs, but googling for arping -U - seems to support the idea that it works most of the time. + correctly to gratuitous ARPs, but googling for arping + -U seems to support the idea that it works most of the + time. To use arping with Proxy ARP in the above example, you would have to: @@ -204,32 +232,32 @@ shorewall start You can call your ISP and ask them to purge the stale ARP cache - entry but many either can't or won't purge individual entries. + entry but many either can't or won't purge individual entries. - You can determine if your ISP's gateway ARP cache is stale using + You can determine if your ISP's gateway ARP cache is stale using ping and tcpdump. Suppose that we suspect that the gateway router has a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows: tcpdump -nei eth0 icmp - Now from 130.252.100.19, ping the ISP's gateway (which we will + Now from 130.252.100.19, ping the ISP's gateway (which we will assume is 130.252.100.254): ping 130.252.100.254 We can now observe the tcpdump output: - 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF) -13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply + 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF) +13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply Notice that the source MAC address in the echo request is different from the destination MAC address in the echo reply!! In this case - 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while + 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57 was the MAC address of the system on the lower left. In - other words, the gateway's ARP cache still associates 130.252.100.19 - with the NIC in that system rather than with the firewall's eth0. + other words, the gateway's ARP cache still associates 130.252.100.19 with + the NIC in that system rather than with the firewall's eth0.
\ No newline at end of file diff --git a/Shorewall-docs2/Shorewall_Doesnt.xml b/Shorewall-docs2/Shorewall_Doesnt.xml index 1d87aa5d1..52f35bc87 100644 --- a/Shorewall-docs2/Shorewall_Doesnt.xml +++ b/Shorewall-docs2/Shorewall_Doesnt.xml @@ -13,7 +13,7 @@ Eastep - 2004-10-26 + 2004-11-14 2003 @@ -91,8 +91,7 @@ Shorewall generally does not contain any support for Netfilter - Patch-O-Matic-ng + Patch-O-Matic-ng features or any other features that require kernel patching -- Shorewall only supports features from released kernels except in unusual cases. diff --git a/Shorewall-docs2/errata.xml b/Shorewall-docs2/errata.xml index 6505e6439..e024b397d 100644 --- a/Shorewall-docs2/errata.xml +++ b/Shorewall-docs2/errata.xml @@ -13,7 +13,7 @@ - 2004-10-25 + 2004-11-12 2001-2004 @@ -69,11 +69,12 @@ Here is the most up to date version of the rfc1918 file. This file only - applies to Shorewall version 2.0.0 and its bugfix updates. In Shorewall - 2.0.1 and later releases, the bogons file lists IP - ranges that are reserved by the IANA and the rfc1918 - file only lists those three ranges that are reserved by rfc1918 file. This file only applies to Shorewall versions 1.4.* and 2.0.0 + and its bugfix updates. In Shorewall 2.0.1 and later releases, + the bogons file lists IP ranges that are reserved by + the IANA and the rfc1918 file only lists those three + ranges that are reserved by RFC 1918.
@@ -81,7 +82,7 @@ Bogons File Here + url="http://shorewall.net/pub/shorewall/errata/2.0.10/bogons">Here is the most up to date version of the bogons file.
diff --git a/Shorewall-docs2/shorewall_setup_guide.xml b/Shorewall-docs2/shorewall_setup_guide.xml index 78f1caeb3..65f1070a2 100644 --- a/Shorewall-docs2/shorewall_setup_guide.xml +++ b/Shorewall-docs2/shorewall_setup_guide.xml @@ -15,7 +15,7 @@ - 2004-10-24 + 2004-11-19 2001-2004 @@ -162,6 +162,17 @@ Zones are defined in the file /etc/shorewall/zones. + + Beginning with Shorewall 2.2.0, the + /etc/shorewall/zones file included in the release + is empty. You can create the above set of zones by copying and pasting + the following into the file: + + net Net Internet +loc Local Local networks +dmz DMZ Demilitarized zone + + Shorewall also recognizes the firewall system as its own zone - by default, the firewall itself is known as fw but that may be changed in the At this point, edit your /etc/shorewall/policy and make any changes that you wish. + + + Beginning with Shorewall 2.2.0, the released policy file is empty. + You can copy and paste the above entries to create a starting point from + which to customize your policies. +
diff --git a/Shorewall2/fallback.sh b/Shorewall2/fallback.sh index f8c78c33f..0ba61aec3 100755 --- a/Shorewall2/fallback.sh +++ b/Shorewall2/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=2.2.0-Beta3 +VERSION=2.2.0-Beta4 usage() # $1 = exit status { diff --git a/Shorewall2/install.sh b/Shorewall2/install.sh index 4c7232a6e..2681e2ff1 100755 --- a/Shorewall2/install.sh +++ b/Shorewall2/install.sh @@ -22,7 +22,7 @@ # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA # -VERSION=2.2.0-Beta3 +VERSION=2.2.0-Beta4 usage() # $1 = exit status { diff --git a/Shorewall2/releasenotes.txt b/Shorewall2/releasenotes.txt index 562ffabf2..711621a0a 100755 --- a/Shorewall2/releasenotes.txt +++ b/Shorewall2/releasenotes.txt @@ -1,4 +1,4 @@ -Shorewall 2.2.0-Beta3 +Shorewall 2.2.0-Beta4 ---------------------------------------------------------------------- Problems Corrected since 2.0.3 diff --git a/Shorewall2/shorewall.spec b/Shorewall2/shorewall.spec index 3d66402b9..d1b3c3038 100644 --- a/Shorewall2/shorewall.spec +++ b/Shorewall2/shorewall.spec @@ -1,6 +1,6 @@ %define name shorewall %define version 2.2.0 -%define release 0Beta3 +%define release 0Beta4 %define prefix /usr Summary: Shoreline Firewall is an iptables-based firewall for Linux systems. @@ -137,6 +137,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Fri Nov 19 2004 Tom Eastep tom@shorewall.net +- Updated to 2.2.0-0Beta3 * Tue Nov 09 2004 Tom Eastep tom@shorewall.net - Updated to 2.2.0-0Beta3 * Tue Nov 02 2004 Tom Eastep tom@shorewall.net diff --git a/Shorewall2/uninstall.sh b/Shorewall2/uninstall.sh index 9eb1c2712..c371a5a51 100755 --- a/Shorewall2/uninstall.sh +++ b/Shorewall2/uninstall.sh @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=2.2.0-Beta3 +VERSION=2.2.0-Beta4 usage() # $1 = exit status {