From d6f388a7556865dc1c7ff998ade7dbde371b1951 Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 28 Jun 2007 20:20:16 +0000 Subject: [PATCH] Third batch of mindless ID changes git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@6696 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- docs/IPIP.xml | 8 +- docs/IPP2P.xml | 6 +- docs/IPSEC-2.6.xml | 14 +- docs/IPSEC.xml | 31 +- docs/Kernel2.6.xml | 78 ---- docs/MAC_Validation.xml | 15 +- docs/Macros.xml | 10 +- docs/Modularization.xml | 10 +- docs/MultiISP.xml | 22 +- docs/Multiple_Zones.xml | 16 +- docs/NAT.xml | 4 +- docs/OPENVPN.xml | 37 +- docs/ipsets.xml | 12 +- docs/kernel.xml | 8 +- docs/myfiles.xml | 936 ---------------------------------------- docs/upgrade_issues.xml | 688 +---------------------------- 16 files changed, 96 insertions(+), 1799 deletions(-) delete mode 100644 docs/Kernel2.6.xml delete mode 100644 docs/myfiles.xml diff --git a/docs/IPIP.xml b/docs/IPIP.xml index d1e9412a4..2c0f56f27 100644 --- a/docs/IPIP.xml +++ b/docs/IPIP.xml @@ -57,7 +57,7 @@ the RPM, the tunnel script may be found in the Shorewall documentation directory (usually /usr/share/doc/shorewall-<version>/). -
+
Bridging two Masqueraded Networks Suppose that we have the following situation: @@ -80,7 +80,7 @@ tunnel_type parameter to the type of tunnel that you want to create. - + /etc/shorewall/tunnel tunnel_type=gre @@ -117,7 +117,7 @@ ipip net 134.28.54.2 In the tunnel script on system A: - + tunnel script on system A tunnel=tosysb @@ -143,7 +143,7 @@ ipip net 206.191.148.9 And in the tunnel script on system B: - + tunnel script on system B tunnel=tosysa diff --git a/docs/IPP2P.xml b/docs/IPP2P.xml index b31024723..d2693ad60 100644 --- a/docs/IPP2P.xml +++ b/docs/IPP2P.xml @@ -45,7 +45,7 @@ release. -
+
Introduction Shorewall verions 2.2.0 and later include support for the ipp2p @@ -57,7 +57,7 @@ Mailing List.
-
+
Scope In the following files, the "PROTO" or "PROTOCOL" column may contain @@ -87,7 +87,7 @@ "ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").
-
+
Example: Example 2 in the ipp2p documentation recommends the following diff --git a/docs/IPSEC-2.6.xml b/docs/IPSEC-2.6.xml index de27fb398..d45c382b8 100644 --- a/docs/IPSEC-2.6.xml +++ b/docs/IPSEC-2.6.xml @@ -69,7 +69,7 @@ using physdev match support" article. -
+
Shorewall 3.0 and Kernel 2.6 IPSEC This is not a HOWTO for Kernel 2.6 @@ -218,7 +218,7 @@ configured.
-
+
IPSec Gateway on the Firewall System Suppose that we have the following sutuation: @@ -455,7 +455,7 @@ sec ipsec mode=tunnel mss=1400
-
+
Mobile System (Road Warrior) Suppose that you have a laptop system (B) that you take with you @@ -464,7 +464,7 @@ sec ipsec mode=tunnel mss=1400 - + Road Warrior VPN You need to define a zone for the laptop or include it in your @@ -648,7 +648,7 @@ RACOON=/usr/sbin/racoon
-
+
Transport Mode In today's wireless world, it is often the case that individual @@ -764,7 +764,7 @@ all all REJECT info
-
+
IPSEC and <trademark>Windows</trademark> XP I have successfully configured my work laptop to use IPSEC with @@ -825,7 +825,7 @@ all all REJECT info
-
+
Source of Additional Samples Be sure to check out the -
+
Preliminary Reading I recommend reading the VPN Basics article if you plan to implement any type of VPN.
-
+
Configuring FreeS/Wan and Derivatives Such as OpenS/Wan There is an excellent guide to configuring IPSEC tunnels at
-
+
IPSec Gateway on the Firewall System Suppose that we have the following sutuation: @@ -224,7 +224,7 @@ vpn loc ACCEPT url="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN.
-
+
VPN Hub using Kernel 2.4 Shorewall can be used in a VPN Hub environment where multiple remote @@ -355,7 +355,7 @@ vpn2 vpn1 ACCEPT
-
+
Mobile System (Road Warrior) Using Kernel 2.4 Suppose that you have a laptop system (B) that you take with you @@ -364,7 +364,7 @@ vpn2 vpn1 ACCEPT - + Road Warrior VPN You need to define a zone for the laptop or include it in your @@ -396,7 +396,7 @@ ipsec net 0.0.0.0/0
-
+
Dynamic RoadWarrior Zones Beginning with Shorewall release 1.3.10, you can define multiple VPN @@ -433,22 +433,5 @@ ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3 and the down part will: /sbin/shorewall delete ipsec0:134.28.54.2 vpn2 - -
- Limitations of Dynamic Zones - - If you include a dynamic zone in the exclude list of a DNAT rule, - the dynamically-added hosts are not excluded from the rule. - - #ACTION SOURCE DEST PROTO DEST PORT(S) -DNAT z!dyn loc:192.168.1.3 tcp 80 - - - dyn=dynamic zone - - Dynamic changes to the zone dyn - will have no effect on the above rule. - -
\ No newline at end of file diff --git a/docs/Kernel2.6.xml b/docs/Kernel2.6.xml deleted file mode 100644 index 72e91c151..000000000 --- a/docs/Kernel2.6.xml +++ /dev/null @@ -1,78 +0,0 @@ - - -
- - - - Shorewall and the 2.6 Linux Kernel - - - - Tom - - Eastep - - - - - - - 2003 - - 2004 - - 2005 - - Thomas M. Eastep - - - - Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 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. - - - -
- General - - Shorewall is compatible with the Linux 2.6 kernel series and - contains support for the following features that are added in that - series: - - - - NETMAP Target Support. - - - - Bridge/Firewall Support - (physdev match support). - - - - CLASSIFY Target - Support. - - -
- -
- IPSEC - - The 2.6 Linux kernel introduces a new implementation of IPSEC which - eliminates the ipsecN device - names. Netfilter/iptables support for this new implementation is - incomplete unless your kernel has been patched. For unpatched kernels, see - the Shorewall IPSEC documentation - (Shorewall support for IPSEC with unpatched 2.6 kernels is very limited). - For patched 2.6 kernels (including those supplied with - SUSE 9.2) see the Kernel 2.6 IPSEC documentation. -
-
\ No newline at end of file diff --git a/docs/MAC_Validation.xml b/docs/MAC_Validation.xml index b54247a6f..9dfefa195 100644 --- a/docs/MAC_Validation.xml +++ b/docs/MAC_Validation.xml @@ -70,7 +70,7 @@ OpenVPN. -
+
Components There are six components to this facility. @@ -154,7 +154,7 @@
-
+
/etc/shorewall/maclist The columns in /etc/shorewall/maclist are: @@ -203,12 +203,11 @@
-
+
Examples - - Here are my files (look <ulink url="myfiles.htm">here</ulink> for - details about my setup) + + Here are my files /etc/shorewall/shorewall.conf: @@ -245,7 +244,7 @@ $WIFI_IF 00:1f:79:cd:fe:2e 192.168.3.6 #Work Laptop - + Router in Wireless Zone Suppose now that I add a second wireless segment to my wireless @@ -264,4 +263,4 @@ $WIFI_IF 00:1f:79:cd:fe:2e 192.168.3.6 #Work Laptop of the host sending the traffic.
- + \ No newline at end of file diff --git a/docs/Macros.xml b/docs/Macros.xml index 616822742..f52b0590b 100644 --- a/docs/Macros.xml +++ b/docs/Macros.xml @@ -47,7 +47,7 @@ release. -
+
Overview of Shorewall Macros? Shorewall macros allow a symbolic name to be associated with a @@ -266,9 +266,11 @@ ACCEPT fw loc tcp 135,139,445 Shorewall versions 3.4 and later include standard 'Reject' and 'Drop' macros that are equivalent to the 'Reject' and 'Drop' actions. + + Default Macros are not supported by Shorewall-perl.
-
+
Defining your own Macros To define a new macro: @@ -572,7 +574,7 @@ bar:debug
-
+
How do I know if I should create an Action or a Macro? While actions and macros perform similar functions, in any given @@ -597,4 +599,4 @@ bar:debug
- + \ No newline at end of file diff --git a/docs/Modularization.xml b/docs/Modularization.xml index 1196f6ff2..f951adae8 100644 --- a/docs/Modularization.xml +++ b/docs/Modularization.xml @@ -34,7 +34,7 @@ -
+
Introduction One of the major changes in Shorewall version 3.4 involved breaking @@ -46,9 +46,9 @@ nothing but function declarations. Shorewall libraries may be loaded into a running shell program using the shell's "." operator. The library files have names which begin with "lib." and are installed in /usr/share/shorewall/. + class="directory">/usr/share/shorewall/. - Individual libraries are of one of two classes. The first class of + Individual libraries are of one of two classes. The first class of libraries are required libraries which, as their name implies, must be included in any Shorewall installation. The other libraries are optional libraries that implement a @@ -56,7 +56,7 @@ based on the requirements of the individual installation.
-
+
Required Libraries Shorewall 3.4 includes the following required libraries. @@ -84,7 +84,7 @@ Shorewall Lite systems.
-
+
Optional Libraries Optional libraries are loaded upon demand based on the user's diff --git a/docs/MultiISP.xml b/docs/MultiISP.xml index 5f1b509c3..08a0e5821 100644 --- a/docs/MultiISP.xml +++ b/docs/MultiISP.xml @@ -73,7 +73,7 @@ -
+
Multiple Internet Connection Support Beginning with Shorewall 2.3.2, limited support is included for @@ -102,7 +102,7 @@ -
+
Overview Let's assume that a firewall is connected via two separate @@ -182,7 +182,7 @@ example.
-
+
/etc/shorewall/providers File Entries in this file have the following columns. As in all @@ -444,7 +444,7 @@
-
+
What an entry in the Providers File Does Adding another entry in the providers file simply creates an @@ -595,7 +595,7 @@ done
-
+
What an entry in the Providers File Does NOT Do Given that Shorewall is simply a tool to configure Netfilter and @@ -670,8 +670,8 @@ DROP:info net:192.168.1.0/24 all net in the SOURCE column.
-
- Example +
+ Example The configuration in the figure at the top of this section would be specified in /etc/shorewall/providers as @@ -784,7 +784,7 @@ eth1 eth2 130.252.99.27
-
+
/etc/shorewall/route_rules The /etc/shorewall/route_rules file was added @@ -810,7 +810,7 @@ eth1 eth2 130.252.99.27 Does. -
+
Routing Rules Routing rules are maintained by the Linux kernel and can be @@ -832,7 +832,7 @@ gateway:~ # with MARK 1 going to Blarg and mark 2 going to Comcast.
-
+
Columns in the route_rules file Columns in the file are: @@ -928,4 +928,4 @@ gateway:~ #Note that because we used a priority of 1000, the
- + \ No newline at end of file diff --git a/docs/Multiple_Zones.xml b/docs/Multiple_Zones.xml index c7b63164a..04bb9e964 100644 --- a/docs/Multiple_Zones.xml +++ b/docs/Multiple_Zones.xml @@ -41,7 +41,7 @@ release. -
+
Introduction While most configurations can be handled with each of the firewall's @@ -103,7 +103,7 @@ be used in exactly the same way.
-
+
Router in the Local Zone Here is an example of a router in the local zone. @@ -116,7 +116,7 @@ -
+
Can You Use the Standard Configuration? In many cases, the standard @@ -141,7 +141,7 @@ restart Shorewall.
-
+
Will One Zone be Enough? If the firewalling requirements for the two local networks is the @@ -170,13 +170,13 @@
-
+
I Need Separate Zones If you need to make 192.168.2.0/24 into its own zone, you can do it one of two ways; Nested Zones or Parallel Zones. -
+
Nested Zones You can define one zone (called it loc) as being @@ -225,7 +225,7 @@ loc loc1 NONE loc1 loc NONE
-
+
Parallel Zones You define both zones in the /etc/shorewall/hosts file to create @@ -265,7 +265,7 @@ loc2 loc1 NONE
-
+
Some Hosts have Special Firewalling Requirements There are cases where a subset of the addresses associated with an diff --git a/docs/NAT.xml b/docs/NAT.xml index b7e003ad8..36ec604cb 100644 --- a/docs/NAT.xml +++ b/docs/NAT.xml @@ -41,7 +41,7 @@ release. -
+
One-to-one NAT @@ -130,7 +130,7 @@ ACCEPT net loc:10.1.1.2 tcp 80 - 130.252.100.18
-
+
ARP cache A word of warning is in order here. ISPs typically configure their diff --git a/docs/OPENVPN.xml b/docs/OPENVPN.xml index d3df370a1..2fb0096fc 100644 --- a/docs/OPENVPN.xml +++ b/docs/OPENVPN.xml @@ -85,14 +85,14 @@ -
+
Preliminary Reading I recommend reading the VPN Basics article if you plan to implement any type of VPN.
-
+
Bridging two Masqueraded Networks Suppose that we have the following situation: @@ -243,7 +243,7 @@ vpn loc ACCEPT the two masqueraded subnetworks can now talk to each other.
-
+
Roadwarrior OpenVPN 2.0 provides excellent support for roadwarriors. Consider @@ -466,7 +466,7 @@ verb 3 have the IP address 192.168.1.8 regardless. -
+
Configuring the Bridge The firewall ran Debian Sarge so the bridge was defined in @@ -495,20 +495,19 @@ iface br0 inet static zone.
-
+
Configuring OpenVPN We used X.509 certificates for authentication. -
+
Firewall (Server) configuration. /etc/openvpn/server-bridge.conf defined a bridge and reserved IP addresses 192.168.1.64-192.168.1.71 for VPN clients. Note that the bridge server only used local IP address 192.168.3.254. We ran two instances of OpenVPN; this one and a second tunnel-mode instance for - remote access (see this - article). + remote access. @@ -553,7 +552,7 @@ verb 3 ifconfig-push 192.168.1.8 255.255.255.0
-
+
Tipper Configuration /etc/openvpn/wireless.conf: @@ -587,7 +586,7 @@ mute-replay-warnings verb 3
-
+
Eastepnc6000 (Windows XP) Configuration C:\Program Files\Openvpn\config\homewireless.ovpn: @@ -619,7 +618,7 @@ persist-key verb 3
-
+
Eastepnc6000 (SUSE 10.0) Configuration The configuration was the same as shown above only with @@ -628,7 +627,7 @@ verb 3
-
+
Configuring Shorewall In this configuration, we didn't need any firewalling between the @@ -639,10 +638,10 @@ verb 3 to configure Shorewall as shown in the Bridge/Firewall documentation. -
+
Firewall -
+
/etc/shorewall/interfaces Note that the bridge (br0) is defined as the interface to the @@ -657,7 +656,7 @@ Wifi eth0 192.168.3.255 dhcp,maclist #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
+
/etc/shorewall/tunnels #TYPE ZONE GATEWAY GATEWAY @@ -667,7 +666,7 @@ openvpnserver:1194 Wifi 192.168.3.0/24
-
+
Tipper Wireless networks pose a threat to all systems that are @@ -675,7 +674,7 @@ openvpnserver:1194 Wifi 192.168.3.0/24 Eastepnc6000 ran Sygate Security Agent and Tipper ran a Shorewall-based Netfilter firewall. -
+
/etc/shorewall/zones #ZONE TYPE OPTIONS IN OUT @@ -686,7 +685,7 @@ net ipv4
-
+
/etc/shorewall/interfaces #ZONE INTERFACE BROADCAST OPTIONS @@ -696,7 +695,7 @@ net eth0 detect routefilter,dhcp,tcpflags #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-
+
/etc/shorewall/policy Since we didn't expect any traffic between the -
+
What are Ipsets? Ipsets are an extention to Netfilter/iptables that are currently @@ -67,7 +67,7 @@ ipsets.
-
+
Shorewall Support for Ipsets Support for ipsets was introduced in Shorewall version 2.3.0. In @@ -119,8 +119,8 @@ ACCEPT +sshok $FW tcp 22 "shorewall save" will save the contents of your ipsets. The file where the sets are saved is formed by taking the name where the Shorewall configuration is stored and appending "-ipsets". So if you enter the - command "shorewall save standard" then Shorewall will save the file as - /var/lib/shorewall/standard-ipsets + command "shorewall save standard" then Shorewall will save the file as + /var/lib/shorewall/standard-ipsets Regardless of the setting of SAVE_IPSETS, the shorewall -f start and shorewall restore commands will @@ -187,7 +187,7 @@ ipset -B Blacklist 206.124.146.177 -b SMTP Now only port 25 will be blocked from 206.124.146.177.
-
+
Defining Dynamic Zones using Ipsets The use of ipsets provides a much better way to define dynamic zones @@ -214,4 +214,4 @@ dyn eth3:+Dyn you're all set. You can add and delete addresses from Dyn without having to touch Shorewall.
- + \ No newline at end of file diff --git a/docs/kernel.xml b/docs/kernel.xml index e741342a5..d93a83630 100644 --- a/docs/kernel.xml +++ b/docs/kernel.xml @@ -40,7 +40,7 @@ url="http://www.kernelnewbies.org">http://www.kernelnewbies.org. -
+
Network Options Configuration Here's a screen shot of my Network Options Configuration:
-
+
Netfilter Configuration Here's a screen shot of my Netfilter configuration:
-
+
Kernel 2.6 Netfilter Options Here's a screenshot of my modularized 2.6 Kernel config (Navigation: @@ -244,7 +244,7 @@ CONFIG_BRIDGE_NF_EBTABLES=m
-
+
Kernel 2.6.16 and Later Netfilter Options Here's a screenshot of my modularized 2.6.16 Kernel config diff --git a/docs/myfiles.xml b/docs/myfiles.xml deleted file mode 100644 index 1e1f4afae..000000000 --- a/docs/myfiles.xml +++ /dev/null @@ -1,936 +0,0 @@ - - -
- - - - About My Network - - - - Tom - - Eastep - - - - - - - 2001-2006 - - Thomas M. Eastep - - - - Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 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. - - - -
- My Current Network - - - I use a combination of One-to-one NAT and Xen paravirtualization, - neither of which are relevant to a simple configuration with a single - public IP address. If you have just a single public IP address, most of - what you see here won't apply to your setup so beware of copying parts - of this configuration and expecting them to work for you. What you copy - may or may not work in your environment. - - - - The configuration shown here corresponds to Shorewall version - 3.0.3. My configuration uses features not available in earlier Shorewall - releases. - - - I have DSL service with 5 static IP addresses (206.124.146.176-180). - My DSL modem (Westell 2200) is - connected to eth2 and has IP address 192.168.1.1 (factory default). The - modem is configured in bridge mode so PPPoE is not - involved. I have a local network connected to eth1 which is bridged to - interface tun0 via bridge br0 (subnet 192.168.1.0/24) and a wireless - network (192.168.3.0/24) connected to eth0. - - In this configuration: - - - - I use one-to-one NAT for "Ursa" (my - personal system that run SUSE 10.0) - Internal address 192.168.1.5 and - external address 206.124.146.178. - - - - I use one-to-one NAT for "lists" (My server - system that runs SUSE 10.0 in a Xen virtual system on - ursa) - Internal address 192.168.1.7 and external - address 206.124.146.177. - - - - I use one-to-one NAT for "Eastepnc6000" (My - work system -- Windows XP SP1/SUSE 10.0). Internal address 192.168.1.6 - and external address 206.124.146.180. - - - - - - use SNAT through 206.124.146.179 for my Wife's Windows XP - system Tarry and our SUSE 10.0 - laptop Tipper which connects - through the Wireless Access Point (wap). - - - - The firewall runs on a Celeron 1.4Ghz under SUSE 10.0. - - Ursa runs Samba for file sharing with the - Windows systems and is configured as a Wins server. - - The wireless network connects to the firewall's eth0 via a LinkSys - WAP11.  In additional to using the rather weak WEP 40-bit encryption - (64-bit with the 24-bit preamble), I use MAC verification and OpenVPN in bridge mode. - - The server in runs Postfix, Courier IMAP (imap and - imaps), DNS (Bind 9), a - Web server (Apache) and an - FTP server - (Pure-ftpd). - - The firewall system itself runs a DHCP server that serves the - local and wireless networks. - - All administration and publishing is done using ssh/scp. I have a - desktop environment installed on the firewall but I usually don't start - it. X applications tunnel through SSH to Ursa or one - of the laptops. The server also has a desktop environment installed but it - is never started. For the most part, X tunneled through SSH is used for - server administration and the server runs at run level 3 (multi-user - console mode on SUSE). - - In addition to the OpenVPN bridge, the firewall hosts an OpenVPN - Tunnel server for VPN access from our second home in Omak, Washington or when we are - otherwise out of town. - - - Eastepnc6000 is shown in both the local LAN - and in the Wifi zone with IP address 192.168.1.6 -- clearly, the - computer can only be in one place or the other. - Tipper can also be in either place and will have - the IP address 192.168.1.8 regardless. - -
- -
- Ursa (Xen) Configuration - - Ursa runs two domains. Domain 0 is my personal Linux desktop - environment. The other domains comprise my DMZ. There is currently only - one system (lists) in the DMZ. - - - - Ursa's Shorewall configuration is described in the article about Xen and Shorewall. - - About the only thing that is unique about the configuration of - Domain 1 (lists) is that its (virtualized) eth0 has two addresses: - - - - 192.168.1.7/24 - - - - 206.124.146.177/32 - - - - This prevents the DNS server from getting confused due to the fact - that the two different views have a different IP addresses for the primary - name server for the domain shorewall.net. -
- -
- Firewall Configuration - -
- Shorewall.conf - -
- STARTUP_ENABLED=Yes -LOGFILE=/var/log/messages -LOGFORMAT="Shorewall:%s:%s:" -LOGTAGONLY=No -LOGRATE= -LOGBURST= -LOGALLNEW= -BLACKLIST_LOGLEVEL= -MACLIST_LOG_LEVEL=$LOG -TCP_FLAGS_LOG_LEVEL=$LOG -RFC1918_LOG_LEVEL=$LOG -SMURF_LOG_LEVEL=$LOG -LOG_MARTIANS=No -IPTABLES= -PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin -SHOREWALL_SHELL=/bin/dash -SUBSYSLOCK= -MODULESDIR= -CONFIG_PATH=/etc/shorewall:/usr/share/shorewall -RESTOREFILE=standard -IPSECFILE=zones -FW= -IP_FORWARDING=On -ADD_IP_ALIASES=No -ADD_SNAT_ALIASES=No -RETAIN_ALIASES=Yes -TC_ENABLED=Internal -CLEAR_TC=Yes -MARK_IN_FORWARD_CHAIN=Yes -CLAMPMSS=Yes -ROUTE_FILTER=No -DETECT_DNAT_IPADDRS=Yes -MUTEX_TIMEOUT=60 -ADMINISABSENTMINDED=Yes -BLACKLISTNEWONLY=Yes -DELAYBLACKLISTLOAD=No -MODULE_SUFFIX= -DISABLE_IPV6=Yes -BRIDGING=No -DYNAMIC_ZONES=No -PKTTYPE=No -RFC1918_STRICT=Yes -MACLIST_TTL=60 -SAVE_IPSETS=No -MAPOLDACTIONS=No -FASTACCEPT=No -BLACKLIST_DISPOSITION=DROP -MACLIST_TABLE=mangle -MACLIST_DISPOSITION=DROP -TCP_FLAGS_DISPOSITION=DROP -
-
- -
- Params File (Edited) - -
- NTPSERVERS=<list of NTP server IP addresses> -POPSERVERS=<list of external POP3 servers accessed by fetchmail running on the DMZ server> -LOG=info -WIFI_IF=eth0 -EXT_IF=eth2 -INT_IF=br0 -OMAK=<ip address of the gateway at our second home> -MIRRORS=<list IP addresses of Shorewall mirrors> -
-
- -
- Zones File - -
- #ZONE TYPE OPTTIONS IN OUT -# OPTIONS OPTIONS -fw firewall -net ipv4 -loc ipv4 -dmz:loc ipv4 -vpn ipv4 -Wifi ipv4 -#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE -
-
- -
- Interfaces File - -
- #ZONE INTERFACE BROADCAST OPTIONS -net $EXT_IF 206.124.146.255 dhcp,norfc1918,logmartians,blacklist,tcpflags,nosmurfs -loc $INT_IF detect dhcp,routeback -vpn tun+ - -Wifi $WIFI_IF - dhcp,maclist -#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE -
-
- -
- Hosts File - - This file is used to define the dmz zone -- the single (virtual) - system with internal IP address 192.168.1.7. - -
- #ZONE HOST(S) OPTIONS -dmz $INT_IF:192.168.1.7 -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE - -
-
- -
- Routestopped File - -
- #INTERFACE HOST(S) OPTIONS -$INT_IF - source,dest -$WIFI_IF - source,dest -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE -
-
- -
- Providers File - -
- This entry isn't necessary but it allows me to smoke test - parsing of the providers file. - - #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY -Blarg 1 1 main $EXT_IF 206.124.146.254 track,balance=1 $INT_IF,$WIFI_IF,tun0 -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - -
-
- -
- Blacklist File (Edited) - -
- I blacklist a number of ports globally to cut down on the amount - of noise in my firewall log. Note that the syntax shown below was - introduced in Shorewall 3.0.3 ("-" in the ADDRESS/SUBNET column); - earlier versions must use "0.0.0.0/0". - - #ADDRESS/SUBNET PROTOCOL PORT -- udp 1024:1033 -- tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898 -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE -
-
- -
- RFC1918 File - -
- Because my DSL modem has an RFC 1918 address (192.168.1.1) and - is connected to eth0, I need to make an exception for that address in - my rfc1918 file. I copied /usr/share/shorewall/rfc1918 to - /etc/shorewall/rfc1918 and changed it as follows: - - #SUBNET TARGET -192.168.1.1 RETURN -172.16.0.0/12 logdrop # RFC 1918 -192.168.0.0/16 logdrop # RFC 1918 -10.0.0.0/8 logdrop # RFC 1918 -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE - -
-
- -
- Policy File - -
- #SOURCE DESTINATION POLICY LOG LEVEL BURST:LIMIT -$FW $FW ACCEPT -loc net ACCEPT -$FW vpn ACCEPT -vpn net ACCEPT -vpn loc ACCEPT -fw Wifi ACCEPT -loc vpn ACCEPT -$FW loc ACCEPT #Firewall to Local -loc $FW REJECT $LOG -net all DROP $LOG 10/sec:40 -all all REJECT $LOG -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE -
-
- -
- Masq File - -
- Although most of our internal systems use one-to-one NAT, my - wife's system (192.168.1.4) uses IP Masquerading (actually SNAT) as do - our wireless network systems and visitors with laptops. - - The first entry allows access to the DSL modem and uses features - introduced in Shorewall 2.1.1. The leading plus sign ("+_") causes the - rule to be placed before rules generated by the /etc/shorewall/nat - file below. - - #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC -+$EXT_IF:192.168.1.1 0.0.0.0/0 192.168.1.254 -$EXT_IF 192.168.0.0/22 206.124.146.179 -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - -
-
- -
- NAT File - -
- #EXTERNAL INTERFACE INTERNAL ALL LOCAL -# INTERFACES -206.124.146.177 $EXT_IF 192.168.1.7 No No -206.124.146.178 $EXT_IF 192.168.1.5 No No -206.124.146.180 $EXT_IF 192.168.1.6 No No -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - -
-
- -
- Tunnels - -
- #TYPE ZONE GATEWAY GATEWAY ZONE PORT -openvpnserver:1194 net 0.0.0.0/0 -openvpnserver:1194 Wifi 192.168.3.0/24 -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE -
-
- -
- Actions File - -
- The Limit action is described in a separate article. - - #ACTION -Mirrors #Accept traffic from the Shorewall Mirror sites -Limit #Limit connection rate from each individual Host -#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE -
-
- -
- action.Mirrors File - -
- $MIRRORS is set in /etc/shorewall/params - above. - - #TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE -# PORT PORT(S) DEST LIMIT -ACCEPT $MIRRORS -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE -
-
- -
- Accounting File - -
- #ACTION CHAIN SOURCE DESTINATION PROTO DEST SOURCE USER/ -# PORT(S) PORT(S) GROUP -hp:COUNT accounting $EXT_IF $INT_IF:192.168.1.6 UDP -hp:COUNT accounting $INT_IF:192.168.1.6 $EXT_IF UDP -DONE hp - -mail:COUNT - $EXT_IF $INT_IF:192.168.1.7 tcp 25 -mail:COUNT - $INT_IF:192.168.1.7 $EXT_IF tcp 25 -DONE mail - -web - $EXT_IF $INT_IF:192.168.1.7 tcp 80 -web - $EXT_IF $INT_IF:192.168.1.7 tcp 443 -web - $INT_IF:192.168.1.7 $EXT_IF tcp 80 -web - $INT_IF:192.168.1.7 $EXT_IF tcp 443 - -COUNT web $EXT_IF $INT_IF:192.168.1.7 -COUNT web $INT_IF:192.168.1.7 $EXT_IF -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE -
-
- -
- Rules File (The shell variables are set in - /etc/shorewall/params) - -
- SECTION NEW -############################################################################################################################################################################### -#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ -# PORT PORT(S) DEST LIMIT GROUP -############################################################################################################################################################################### -REJECT:$LOG loc net tcp 25 -REJECT:$LOG loc net udp 1025:1031 -# -# Stop NETBIOS crap -# -REJECT loc net tcp 137,445 -REJECT loc net udp 137:139 -# -# Stop my idiotic work laptop from sending to the net with an HP source/dest IP address -# -DROP loc:!192.168.0.0/22 net -DROP Wifi net:15.0.0.0/8 -DROP Wifi net:16.0.0.0/8 -############################################################################################################################################################################### -# Local Network to Firewall -# -DROP loc:!192.168.0.0/22 fw # Silently drop traffic with an HP source IP from my XP box -Limit:$LOG:SSHA,3,60\ - loc fw tcp 22 -ACCEPT loc fw tcp time,631,8080 -ACCEPT loc fw udp 161,ntp,631 -ACCEPT loc:192.168.1.5 fw udp 111 -DROP loc fw tcp 3185 #SUSE Meta pppd -Ping/ACCEPT loc fw -############################################################################################################################################################################### -# Local Network to Wireless -# -Ping/ACCEPT loc Wifi -############################################################################################################################################################################### -# Insecure Wireless to DMZ -# -ACCEPT Wifi dmz udp domain -ACCEPT Wifi dmz tcp domain -############################################################################################################################################################################### -# Insecure Wireless to Internet -# -ACCEPT Wifi net udp 500 -ACCEPT Wifi net udp 4500 -ACCEPT Wifi:192.168.3.9 net all -Ping/ACCEPT Wifi net -############################################################################################################################################################################### -# Insecure Wireless to Firewall -# -SSH/ACCEPT Wifi fw -############################################################################################################################################################################### -# Road Warriors to Firewall -# -ACCEPT vpn fw tcp ssh,time,631,8080 -ACCEPT vpn fw udp 161,ntp,631 -Ping/ACCEPT vpn fw -############################################################################################################################################################################### -# Road Warriors to DMZ -# -ACCEPT vpn dmz udp domain -ACCEPT vpn dmz tcp www,smtp,smtps,domain,ssh,imap,https,imaps,ftp,10023,pop3 - -Ping/ACCEPT vpn dmz -############################################################################################################################################################################### -# Local network to DMZ -# -ACCEPT loc dmz udp domain -ACCEPT loc dmz tcp ssh,smtps,www,ftp,imaps,domain,https - -ACCEPT loc dmz tcp smtp -ACCEPT loc dmz udp 33434:33454 -############################################################################################################################################################################### -# Internet to ALL -- drop NewNotSyn packets -# -dropNotSyn net fw tcp -dropNotSyn net loc tcp -dropNotSyn net dmz tcp -############################################################################################################################################################################### -# Internet to DMZ -# -ACCEPT net dmz udp domain -LOG:$LOG net:64.126.128.0/18 dmz tcp smtp -ACCEPT net dmz tcp smtps,www,ftp,imaps,domain,https - -ACCEPT net dmz tcp smtp - 206.124.146.177,206.124.146.178 -ACCEPT net dmz udp 33434:33454 -Mirrors net dmz tcp rsync -Limit:$LOG:SSHA,3,60\ - net dmz tcp 22 -Ping/ACCEPT net dmz -############################################################################################################################################################################### -# -# Net to Local -# -########################################################################################## -# Test Server -# -ACCEPT net loc:192.168.1.9 tcp 80 -ACCEPT net loc:192.168.1.9 tcp 443 -ACCEPT net loc:192.168.1.9 tcp 21 -Ping/ACCEPT net loc:192.168.1.9 -# -# When I'm "on the road", the following two rules allow me VPN access back home using PPTP. -# -DNAT net loc:192.168.1.4 tcp 1729 -DNAT net loc:192.168.1.4 gre -# -# Roadwarrior access to Ursa -# -ACCEPT net:$OMAK loc tcp 22 -Limit:$LOG:SSHA,3,60\ - net loc tcp 22 -# -# ICQ -# -ACCEPT net loc:192.168.1.5 tcp 113,4000:4100 -# -# Bittorrent -# -ACCEPT net loc:192.168.1.5 tcp 6881:6889,6969 -ACCEPT net loc:192.168.1.5 udp 6881:6889,6969 -# -# Real Audio -# -ACCEPT net loc:192.168.1.5 udp 6970:7170 -# -# Overnet -# -#ACCEPT net loc:192.168.1.5 tcp 4662 -#ACCEPT net loc:192.168.1.5 udp 12112 -# -# OpenVPN -# -ACCEPT net loc:192.168.1.5 udp 1194 -# -# Skype -# -ACCEPT net loc:192.168.1.6 tcp 1194 -# -# Silently Handle common probes -# -REJECT net loc tcp www,ftp,https -DROP net loc icmp 8 -############################################################################################################################################################################### -# DMZ to Internet -# -ACCEPT dmz net udp domain,ntp -ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,https,cvspserver,2702,2703,8080 -ACCEPT dmz net:$POPSERVERS tcp pop3 -Ping/ACCEPT dmz net -# -# Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking -# code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases -# but logs the connection so I can keep an eye on this potential security hole. -# -ACCEPT:$LOG dmz net tcp 1024: 20 -############################################################################################################################################################################### -# DMZ to Firewall -- ntp & snmp, Silently reject Auth -# -ACCEPT dmz fw udp ntp ntp -ACCEPT dmz fw tcp 161,ssh -ACCEPT dmz fw udp 161 -REJECT dmz fw tcp auth -Ping/ACCEPT dmz fw -############################################################################################################################################################################### -# Internet to Firewall -# -REJECT net fw tcp www,ftp,https -DROP net fw icmp 8 -ACCEPT net fw udp 33434:33454 -ACCEPT net:$OMAK fw udp ntp -ACCEPT net fw tcp auth -ACCEPT net:$OMAK fw tcp 22 -Limit:$LOG:SSHA,3,60\ - net fw tcp 22 -############################################################################################################################################################################### -# Firewall to Internet -# -ACCEPT fw net:$NTPSERVERS udp ntp ntp -#ACCEPT fw net:$POPSERVERS tcp pop3 -ACCEPT fw net udp domain -ACCEPT fw net tcp domain,www,https,ssh,1723,whois,1863,ftp,2702,2703,7 -ACCEPT fw net udp 33435:33535 -ACCEPT fw net icmp -REJECT:$LOG fw net udp 1025:1031 -DROP fw net udp ntp -Ping/ACCEPT fw net -############################################################################################################################################################################### -# Firewall to DMZ -# -ACCEPT fw dmz tcp domain,www,ftp,ssh,smtp,993,465 -ACCEPT fw dmz udp domain -REJECT fw dmz udp 137:139 -Ping/ACCEPT fw dmz -############################################################################################################################################################################### -# Firewall to Insecure Wireless -# -Ping/ACCEPT fw Wifi -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE - -
-
- -
- /etc/shorewall/tcdevices - -
- #INTERFACE IN-BANDWITH OUT-BANDWIDTH -$EXT_IF 1.5mbit 384kbit -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE -
-
- -
- /etc/shorewall/tcclasses - -
- My traffic shaping configuration is basically the "WonderShaper" - example - from tc4shorewall with a little tweaking. - - #INTERFACE MARK RATE CEIL PRIORITY OPTIONS -$EXT_IF 10 full ful 1 tcp-ack,tos-minimize-delay -$EXT_IF 20 9*full/10 9*full/10 2 default -$EXT_IF 30 6*full/10 6*full/10 3 -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE -
-
- -
- /etc/shorewall/tcrules - -
- I give full bandwidth to my local systems -- the server gets - throttled and rsync gets throttled even more. - - - The class id for tc4shorewall-generated classes is - <device number>:<100 + mark - value> where the first device in - /etc/shorewall/tcdevices is device number 1, - the second is device number 2 and so on. The rules below are using - the Netfilter CLASSIFY target to classify the traffic directly - without having to first mark then classify based on the - marks. - - - #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST -# PORT(S) -1:110 192.168.0.0/22 $EXT_IF -1:130 206.124.146.177 $EXT_IF tcp - 873 #Rsync to the Mirrors -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE - - Here is the output of shorewall show tc while - the Shorewall mirrors were receiving updates via rsync and the link - was otherwise idle. Note the rate limiting imposed by the 1:30 - Class. - - Shorewall-3.0.0-RC2 Traffic Control at gateway - Sat Oct 22 09:11:26 PDT 2005 - -... - -Device eth2: -qdisc htb 1: r2q 10 default 120 direct_packets_stat 2 ver 3.17 - Sent 205450106 bytes 644093 pkts (dropped 0, overlimits 104779) - backlog 20p -qdisc ingress ffff: ---------------- - Sent 160811382 bytes 498294 pkts (dropped 37, overlimits 0) -qdisc sfq 110: parent 1:110 limit 128p quantum 1514b flows 128/1024 perturb 10sec - Sent 81718034 bytes 417516 pkts (dropped 0, overlimits 0) -qdisc sfq 120: parent 1:120 limit 128p quantum 1514b flows 128/1024 perturb 10sec - Sent 61224535 bytes 177773 pkts (dropped 0, overlimits 0) -qdisc sfq 130: parent 1:130 limit 128p quantum 1514b flows 128/1024 perturb 10sec - Sent 62507157 bytes 48802 pkts (dropped 0, overlimits 0) - backlog 20p -class htb 1:110 parent 1:1 leaf 110: prio 1 quantum 4915 rate 384000bit ceil 384000bit burst 1791b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 0 - Sent 81718034 bytes 417516 pkts (dropped 0, overlimits 0) - rate 424bit - lended: 417516 borrowed: 0 giants: 0 - tokens: 36864 ctokens: 36864 - -class htb 1:1 root rate 384000bit ceil 384000bit burst 1791b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 7 - Sent 205422474 bytes 644073 pkts (dropped 0, overlimits 0) - rate 231568bit 19pps - lended: 0 borrowed: 0 giants: 0 - tokens: -26280 ctokens: -26280 - -class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 2944 rate 230000bit ceil 230000bit burst 1714b/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 - Sent 62507157 bytes 48802 pkts (dropped 0, overlimits 0) - rate 230848bit 19pps backlog 18p - lended: 48784 borrowed: 0 giants: 0 - tokens: -106401 ctokens: -106401 - -class htb 1:120 parent 1:1 leaf 120: prio 2 quantum 4416 rate 345000bit ceil 345000bit burst 1771b/8 mpu 0b overhead 0b cburst 1771b/8 mpu 0b overhead 0b level 0 - Sent 61224535 bytes 177773 pkts (dropped 0, overlimits 0) - rate 1000bit - lended: 177773 borrowed: 0 giants: 0 - tokens: 41126 ctokens: 41126 - -... -
-
- -
- /etc/openvpn/server.conf - - Only the tunnel-mode OpenVPN configuration is described here -- - the bridge is described in the OpenVPN - documentation. - -
- dev tun - -local 206.124.146.176 - -server 192.168.2.0 255.255.255.0 - -dh dh1024.pem - -ca /etc/certs/cacert.pem - -crl-verify /etc/certs/crl.pem - -cert /etc/certs/gateway.pem -key /etc/certs/gateway_key.pem - -port 1194 - -comp-lzo - -user nobody -group nogroup - -keepalive 15 45 -ping-timer-rem -persist-tun -persist-key - -client-config-dir /etc/openvpn/clients -ccd-exclusive -client-to-client - -verb 3 -
-
-
- -
- Tipper and Eastepnc6000 Configuration in the Wireless - Network - - Please find this information in the OpenVPN bridge mode - documentation. -
- -
- Tipper Configuration while on the Road - - This laptop is either configured on our wireless network - (192.168.3.8) or as a standalone system on the road. - - Tipper's view of the world is shown in the - following diagram: - - - -
- zones - -
- #ZONE DISPLAY COMMENTS -home Home Shorewall Network -net Net Internet -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - -
-
- -
- policy - -
- #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST -$FW net ACCEPT -$FW home ACCEPT -home $FW ACCEPT -net home NONE -home net NONE -net all DROP info -# The FOLLOWING POLICY MUST BE LAST -all all REJECT info -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE -
-
- -
- interfaces - -
- #ZONE INTERFACE BROADCAST OPTIONS -net eth0 detect dhcp,tcpflags -home tun0 - -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE -
-
- -
- rules - -
- #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ -# PORT PORT(S) DEST LIMIT GROUP -ACCEPT net $FW icmp 8 -ACCEPT net $FW tcp 22 -ACCEPT net $FW tcp 4000:4100 -#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE -
-
- -
- /etc/openvpn/home.conf - -
- dev tun -remote gateway.shorewall.net -up /etc/openvpn/home.up - -tls-client -pull - -ca /etc/certs/cacert.pem - -cert /etc/certs/tipper.pem -key /etc/certs/tipper_key.pem - -port 1194 - -user nobody -group nogroup - -comp-lzo - -ping 15 -ping-restart 45 -ping-timer-rem -persist-tun -persist-key - -verb 3 -
-
- -
- /etc/openvpn/home.up - -
- #!/bin/bash - -ip route add 192.168.1.0/24 via $5 #Access to Home Network -ip route add 206.124.146.177/32 via $5 #So that DNS names will resolve in my - #Internal Bind 9 view because the source IP will - #be in 192.168.2.0/24 -
-
-
-
diff --git a/docs/upgrade_issues.xml b/docs/upgrade_issues.xml index ff0e88968..19b7f63d7 100644 --- a/docs/upgrade_issues.xml +++ b/docs/upgrade_issues.xml @@ -43,7 +43,7 @@ -
+
Important It is important that you read all of the sections on this page where @@ -69,12 +69,12 @@ command to see the groups associated with each of your zones.
-
+
Versions >= 4.0.0-Beta1 - This is the first Shorewall release that fully integrates the + This is the first Shorewall release that fully integrates the new Shorewall-perl compiler. You are now offered a choice as to which compiler(s) you install. In Shorewall 4.0.0, there are the following packages: @@ -123,12 +123,12 @@ rpm -U shorewall-4.0.0.noarch.rpmIf you are upgrading using caused the corresponding flag in /proc to be reset for all interfaces. Beginning in Shorewall 4.0.0, leaving these options empty causes Shorewall to leave the flags in /proc as they are. You must set the - option to 'No' in order to obtain the old behavior. + option to 'No' in order to obtain the old behavior.
-
+
Versions >= 3.4.0-Beta1 @@ -336,7 +336,7 @@ all all REJECT:MyReject info
-
+
Version >= 3.2.0 @@ -546,7 +546,7 @@ all all REJECT:MyReject info
-
+
Version >= 3.0.0 @@ -687,7 +687,7 @@ rejNotSyn:info net all tcp
-
+
Version >= 2.4.0 @@ -714,676 +714,4 @@ rejNotSyn:info net all tcp
- -
- Version >= 2.2.0 - - - - 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. - - - - The default port for 'openvpn' tunnels (/etc/shorewall/tunnels) - has been changed to 1194 to match a similar change in the OpenVPN - product. The IANA has registered port 1194 for use by OpenVPN. - - - - A new IPTABLES variable has been added to shorewall.conf. This - variable names the iptables executable that Shorewall will use. The - variable is set to "/sbin/iptables". If you use the new - shorewall.conf, you may need to change this setting to maintain - compatibility with your current setup (if you use your existing - shorewall.conf that does not set IPTABLES then you should experience - no change in behavior). - - -
- -
- 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. - - -
- -
- Version >= 2.0.2 Beta 1 - - - - Extension Scripts - In order for extension scripts to work - properly with the new iptables-save/restore integration introduced in - Shorewall 2.0.2 Beta 1, some change may be required to your extension - scripts. - - 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 completion - of the /sbin/shorewall command). The following - functions should be of help: - - - - save_command() -- saves the passed command to the restore - file. - - Example: save_command echo Operation Complete - - 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" - - Note that as in this example, when the command involves file - redirection then the entire command must be enclosed in quotes. - This applies to all of the functions described here. - - - - ensure_and_save_command() -- runs the passed command. If the - command fails, the firewall is restored to its 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. - - -
- -
- 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. - - - If you have a file named rfc1918 in your - /etc/shorewall directory, you - must either remove that file or you must copy - /usr/share/shorewall/rfc1918 to /etc/shorewall and modify that file - appropriately. Do not leave the old rfc1918 - file in /etc/shorewall. - - - -
- -
- VERSION >= 2.0.0-Beta1 - - - - 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. - - - - 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 precedence 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. - - - - The following files don't exist in Shorewall 2.0: - - - /etc/shorewall/common.def - - /etc/shorewall/common - - /etc/shorewall/icmpdef - - /etc/shorewall/action.template (moved - 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). - - The file /usr/share/shorewall/actions.std has been added to - define those actions that are released as part of Shorewall 2.0 In - that file are two actions as follows: - - - Drop:DROP - - Reject:REJECT - - - The Drop action is the common action for DROP - 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. - - 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. - - - - The /etc/shorewall directory no longer - 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. - - - - The last column in /etc/shorewall/rules is - now labeled USER/GROUP and may contain: - - - [!]<user number>[:] - - [!]<user name>[:] - - [!]:<group number> - - [!]:<group name> - - [!]<user - number>:<group - number> - - [!]<user - name>:<group - number> - - [!]<user - inumber>:<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. - You must have ipv6tables installed. - - -
- -
- Version >= 1.4.9 - - - - The default value of NEWNOTSYN set in /etc/shorewall/shorewall.conf has - been changed from 'No' to 'Yes'. I find that NEWNOTSYN=No tends to - result in lots of "stuck" connections because any network timeout - during TCP session tear down results in retries being dropped - (Netfilter has removed the connection from the conntrack table but the - end-points haven't completed shutting down the connection). I - therefore have chosen NEWNOTSYN=Yes as the default value and I advise - caution in using NEWNOTSYN=Yes. - - -
- -
- 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 - ROUTE_FILTER=Yes and use the routefilter option in - /etc/shorewall/interfaces - entries. - - -
- -
- 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. - - - - 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 - - - -
- -
- 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 - 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: - - 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 - - - - Beginning with Version 1.4.1, traffic between groups in the same - zone is accepted by default. Previously, traffic from a zone to itself - 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. - - - - 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. - - - - 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. - - - - 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. - - - - - - 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 - - -/etc/shorewall/zones -z1 Zone1 The first Zone -z2 Zone2 The second 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: - 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 asymmetric routing where only the traffic on one - direction flows through the firewall and you are using a NONE policy - in the other direction. - - -
- -
- Version 1.4.1 - - - - 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. - - -
- -
- Version >= 1.4.0 - - - Shorewall >=1.4.0 requires the iproute - 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-1This - 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. - - -
- -
- Version 1.4.0 - - - - 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. - - - - -
\ No newline at end of file