From 575e27ca249b7900fa17652fd25db75ed24450f1 Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 19 Aug 2004 18:29:13 +0000 Subject: [PATCH] Documentation Updates git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1558 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/FAQ.xml | 18 +++++-- Shorewall-docs2/IPSEC-2.6.xml | 56 ++++++++++++++++++++- Shorewall-docs2/bridge.xml | 93 +++++++++++++++++++---------------- 3 files changed, 120 insertions(+), 47 deletions(-) diff --git a/Shorewall-docs2/FAQ.xml b/Shorewall-docs2/FAQ.xml index 5b7e85273..21106f067 100644 --- a/Shorewall-docs2/FAQ.xml +++ b/Shorewall-docs2/FAQ.xml @@ -17,7 +17,7 @@ - 2004-08-10 + 2004-08-19 2001-2004 @@ -1776,9 +1776,9 @@ Creating input Chains... with your new kernel.
- (FAQ 27a) I just built and installed a new kernel and now - Shorewall won't start. I know that my kernel options are - correct. + (FAQ 27a) I just built (or downloaded or otherwise acquired) + and installed a new kernel and now Shorewall won't start. I know that + my kernel options are correct. The last few lines of a startup trace are these: @@ -1816,6 +1816,16 @@ iptables: Invalid argument Revision History + + 1.29 + + 2004-08-19 + + TE + + Reword FAQ 27a to include downloaded kernels. + + 1.28 diff --git a/Shorewall-docs2/IPSEC-2.6.xml b/Shorewall-docs2/IPSEC-2.6.xml index c240c8b33..7afb4f2e2 100644 --- a/Shorewall-docs2/IPSEC-2.6.xml +++ b/Shorewall-docs2/IPSEC-2.6.xml @@ -15,7 +15,7 @@ - 2004-08-15 + 2004-08-18 2004 @@ -46,6 +46,60 @@ the responsible Netfilter developer who has confirmed the problem. +
+ Shorewall 2.1 and Kernel 2.6 IPSEC + + The 2.6 Linux Kernel introduces new facilities for defining + encrypted communication between hosts in a network. The network + administrator defines a set of Security Policies which are stored in the + kernel as a Security Policy Database (SPD). Outgoing traffic is encrypted + according to the contents of the SPD and incoming traffic is verified + against the SPD to ensure that no unencrypted traffic is accepted in + violation of the administrator's policies. + + There are three ways in which IPSEC traffic can interact with + Shorewall policies and rules: + + + + Traffic that is encrypted on the firewall system. The traffic + passes through Netfilter twice -- first as unencrypted then + encrypted. + + + + Traffic that is decrypted on the firewall system. The traffic + passes through Netfilter twice -- first as encrypted then as + unencrypted. + + + + Encrypted traffic that is passed through the firewall system. + The traffic passes through Netfilter once. + + + + In cases 1 and 2, the encrypted traffic is handled by entries in + /etc/shorewall/tunnels (don't be mislead by the name + of the file -- transport mode encrypted traffic is + also handled by entries in that file). The unencrypted traffic is handled + by normal rules and policies. + + Under the 2.4 Linux Kernel, the association of unencrypted traffic + and zones was made easy by the presense of IPSEC pseudo-interfaces with + names of the form ipsecn (e.g. + ipsec0). Outgoing unencrypted + traffic (case 1.) was send through an ipsecn device while incoming unencrypted + traffic (case 2) arrived from an ipsecn device. The 2.6 kernel-based + implementation does away with these pseudo-interfaces. Outgoing traffic + that is going to be encrypted and incoming traffic that has been decrypted + must be matched against policies in the SPD. + + +
+
IPSec Gateway on the Firewall System diff --git a/Shorewall-docs2/bridge.xml b/Shorewall-docs2/bridge.xml index 388012cb1..8b3ec0c3b 100755 --- a/Shorewall-docs2/bridge.xml +++ b/Shorewall-docs2/bridge.xml @@ -15,7 +15,7 @@ - 2004-07-31 + 2004-08-19 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. @@ -60,7 +61,8 @@ - A router cannot forward broadcast packets while a bridge can. + A router cannot forward broadcast packets while a bridge + can.
@@ -80,7 +82,8 @@ Your kernel must contain Netfilter physdev match support (CONFIG_IP_NF_MATCH_PHYSDEV=m or CONFIG_IP_NF_MATCH_PHYSDEV=y). Physdev match is standard in the 2.6 kernel series but must be patched - into the 2.4 kernels (see http://bridge.sf.net). + into the 2.4 kernels (see http://bridge.sf.net). @@ -108,7 +111,7 @@ between the router and the systems in the local network. In the example shown, the network uses RFC 1918 addresses but that is not a requirement; the bridge would work exactly the same if public IP addresses were used - (remember that the bridge doesn't deal with IP addresses). + (remember that the bridge doesn't deal with IP addresses). @@ -125,13 +128,13 @@ The systems connected to the LAN are configured with the - router's IP address (192.168.1.254 in the above diagram) as their + router's IP address (192.168.1.254 in the above diagram) as their default gateway. - traceroute doesn't detect the - Bridge/Firewall as an intermediate router. + traceroute doesn't detect the Bridge/Firewall + as an intermediate router. @@ -157,9 +160,9 @@ configuration information may be found at http://bridge.sf.net. - Unfortunately, Linux distributions don't have good bridge - configuration tools and the network configuration GUIs don't detect - the presence of bridge devices. You may refer to my + Unfortunately, Linux distributions don't have good bridge + configuration tools and the network configuration GUIs don't detect the + presence of bridge devices. You may refer to my configuration files for an example of configuring a three-port bridge at system boot under SuSE. Here is an excerpt from a Debian /etc/network/interfaces file @@ -183,22 +186,24 @@ iface br0 inet static doing so allows the bridge/firewall to access other systems and allows the bridge/firewall to be managed remotely. The bridge must also have an IP address for REJECT rules and policies to work correctly — otherwise REJECT - behaves the same as DROP. + behaves the same as DROP. It is also a requirement for bridges to have an + IP address if they are part of a bridge/router. - The bridge may have its IP address assigned via DHCP. Here's an + The bridge may have its IP address assigned via DHCP. Here's an example of an /etc/sysconfig/network/ifcfg-br0 file from a SuSE system:
- BOOTPROTO='dhcp' -REMOTE_IPADDR='' -STARTMODE='onboot' -UNIQUE='3hqH.MjuOqWfSZ+C' -WIRELESS='no' -MTU='' + BOOTPROTO='dhcp' +REMOTE_IPADDR='' +STARTMODE='onboot' +UNIQUE='3hqH.MjuOqWfSZ+C' +WIRELESS='no' +MTU=''
- Here's an /etc/sysconfig/network-scripts/ifcfg-br0 file for a + Here's an /etc/sysconfig/network-scripts/ifcfg-br0 file for a Mandrake system:
@@ -209,7 +214,8 @@ ONBOOT=yes On both the SuSE and Mandrake systems, a separate script is required to configure the bridge itself (again see my - configuration files for an example - /etc/init.d/bridge). + configuration files for an example - + /etc/init.d/bridge). Axel Westerhold has contributed this example of configuring a bridge with a static IP address on a Fedora System (Core 1 and Core 2 Test 1). @@ -243,12 +249,12 @@ ONBOOT=yes # description: Layer 2 Bridge # -[ -f /etc/sysconfig/bridge ] && . /etc/sysconfig/bridge +[ -f /etc/sysconfig/bridge ] && . /etc/sysconfig/bridge PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin do_stop() { - echo "Stopping Bridge" + echo "Stopping Bridge" for i in $INTERFACES $BRIDGE_INTERFACE ; do ip link set $i down done @@ -257,7 +263,7 @@ do_stop() { do_start() { - echo "Starting Bridge" + echo "Starting Bridge" for i in $INTERFACES ; do ip link set $i up done @@ -269,7 +275,7 @@ do_start() { ifup $BRIDGE_INTERFACE } -case "$1" in +case "$1" in start) do_start ;; @@ -282,7 +288,7 @@ case "$1" in do_start ;; *) - echo "Usage: $0 {start|stop|restart}" + echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0 @@ -290,7 +296,7 @@ exit 0 The /etc/sysconfig/bridge file: BRIDGE_INTERFACE=br0 #The name of your Bridge -INTERFACES="eth0 eth1" #The physical interfaces to be bridged +INTERFACES="eth0 eth1" #The physical interfaces to be bridged
Andrzej Szelachowski contributed the following. @@ -298,15 +304,15 @@ INTERFACES="eth0 eth1" #The physical interfaces to be bridged Here is how I configured bridge in Slackware: -1) I had to compile bridge-utils (It's not in the standard distribution) -2) I've created rc.bridge in /etc/rc.d: +1) I had to compile bridge-utils (It's not in the standard distribution) +2) I've created rc.bridge in /etc/rc.d: ######################### #! /bin/sh ifconfig eth0 0.0.0.0 ifconfig eth1 0.0.0.0 -#ifconfig lo 127.0.0.1 #this line should be uncommented if you don't use rc.inet1 +#ifconfig lo 127.0.0.1 #this line should be uncommented if you don't use rc.inet1 brctl addbr most @@ -315,7 +321,7 @@ brctl addif most eth1 ifconfig most 192.168.1.31 netmask 255.255.255.0 up #route add default gw 192.168.1.1 metric 1 #this line should be uncommented if - #you don't use rc.inet1 + #you don't use rc.inet1 ######################### 3) I made rc.brige executable and added the following line to /etc/rc.d/rc.local @@ -356,16 +362,17 @@ all all REJECT info #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE Only the bridge device itself is configured with an IP address so - only that device is defined to Shorewall in /etc/shorewall/interfaces: + only that device is defined to Shorewall in + /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - br0 192.168.1.255 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE - The zones are defined using the /etc/shorewall/hosts - file. Assuming that the router is connected to eth0 and the switch to eth1: + The zones are defined using the + /etc/shorewall/hosts file. Assuming that the router + is connected to eth0 and the + switch to eth1: #ZONE HOST(S) OPTIONS net br0:eth0 @@ -373,7 +380,8 @@ loc br0:eth1 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE When Shorewall is stopped, you want to allow only local traffic - through the bridge — /etc/shorewall/routestopped: + through the bridge — + /etc/shorewall/routestopped: #INTERFACE HOST(S) OPTIONS br0 192.168.1.0/24 routeback @@ -384,11 +392,11 @@ br0 192.168.1.0/24 routeback firewall rules.
-
+
Combination Router/Bridge - A system running Shorewall doesn't have to be exclusively a - bridge or a router -- it can act as both. Here's an example:A system running Shorewall doesn't have to be exclusively a bridge + or a router -- it can act as both. Here's an example: This is basically the same setup as shown in the - The /etc/shorewall/hosts file would have: + The /etc/shorewall/hosts file would + have: #ZONE HOSTS OPTIONS net br0:eth0 @@ -422,7 +431,7 @@ dmz br0:eth2
Limitations - Bridging doesn' t work with some wireless cards — see Bridging doesn' t work with some wireless cards — see http://bridge.sf.net.
\ No newline at end of file