From 17eff43202857b045fc386fad2051268ad5268ce Mon Sep 17 00:00:00 2001 From: teastep Date: Sun, 7 May 2006 14:55:44 +0000 Subject: [PATCH] Some 3.2.0 Documentation Updates git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3891 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- docs/Documentation.xml | 121 ++++++++++++++++++++++++++++++++++++++++- docs/MultiISP.xml | 31 +++++++++-- 2 files changed, 146 insertions(+), 6 deletions(-) diff --git a/docs/Documentation.xml b/docs/Documentation.xml index b43e85c44..3b3b1cf66 100644 --- a/docs/Documentation.xml +++ b/docs/Documentation.xml @@ -15,7 +15,7 @@ - 2006-04-23 + 2006-05-07 2001-2006 @@ -2742,6 +2742,125 @@ eth0 eth1 206.124.146.176 This file is used to set the following firewall parameters: + + VERBOSITY (Added in version 3.2.0) + + + Shorewall has traditionally been very noisy (produced lots of + output). You may now set the default level of verbosity using the + VERBOSITY OPTION. + + Values are: + + + 0 — Silent. You may make it more verbose using the -v + option + + 1 — Major progress messages displayed + + 2 — All progress messages displayed (old default + behavior) + + + If not specified, then 2 is assumed. + + + + + IMPLICIT_CONTINUE (Added in version 3.2.0) + + + When this option is set to "Yes", it causes subzones to be + treated differently with respect to policies. + + Subzones are defined by following their name with ":" and a + list of parent zones (in /etc/shorewall/zones). Normally, you want + to have a set of special rules for the subzone and if a connection + doesn't match any of those subzone-specific rules then you want the + parent zone rules and policies to be applied. With + IMPLICIT_CONTINUE=Yes, that happens automatically. + + If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, + then subzones are not subject to this special treatment. With + IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden + by including an explicit policy (one that does not specify "all" in + either the SOURCE or the DEST columns). + + Example: + +
+ /etc/shorewall/zones: + + #ZONE TYPE +prnt ipv4 +chld:prnt ipv4 + + Traffic to/from the chld + zone will first pass through the applicable chld rules and if none of those rules match + then it will be passed through the appropriate prnt rules. If the connection request does + not match any of the prnt rules + then the relevant prnt policy is + applied. + + If you want the fw->chld policy to be ACCEPT, simply add this + entry to /etc/shorewall/policy: + + #SOURCE DESTINATION POLICY +$FW chld ACCEPT + + Traffic from all other zones to 'chld' will be subject to + the implicit CONTINUE policy. +
+ + + + + HIGH_ROUTE_MARKS (Added in version 3.2.0) + + + Prior to version 3.2.0, it was not possible to use connection + marking in /etc/shorewall/tcrules if you have a + multi-ISP configuration that uses the track option. + + Beginning with release 3.2.0, you may now set + HIGH_ROUTE_MARKS=Yes in to effectively divide the packet mark and + connection mark into two 8-byte mark fields. + + When you do this: + + + + The MARK field in the providers file + must have a value that is less than 65536 and that is a multiple + of 256 (using hex representation, the values are 0x0100-0xFF00 + with the low-order 8 bits being zero). + + + + You may only set those mark values in the PREROUTING + chain. + + + + Marks used for traffic shaping must still be in the range + of 1-255 and may still not be set in the PREROUTING + chain. + + + + When you SAVE or RESTORE in tcrules, only the TC mark + value is saved or restored. Shorewall handles saving and + restoring the routing (provider) marks. + + + + + FASTACCEPT diff --git a/docs/MultiISP.xml b/docs/MultiISP.xml index 658d29ebf..8c4effa87 100644 --- a/docs/MultiISP.xml +++ b/docs/MultiISP.xml @@ -15,7 +15,7 @@ - 2006-05-06 + 2006-05-07 2005 @@ -207,8 +207,27 @@ A mark value used in your /etc/shorewall/tcrules file to direct packets to this provider. Shorewall will also mark connections that have seen input from this provider with this - value and will restore the packet mark in the PREROUTING - CHAIN. + value and will restore the packet mark in the PREROUTING CHAIN. + Mark values must be in the range 1-255. + + Beginning with Shorewall version 3.2.0 Beta 6, you may use + may set HIGH_ROUTE_MARKS=Yes in + /etc/shorewall/shorewall.conf. This allows + you to: + + + + Use connection marks for traffic shaping, provided that + you assign those marks in the FORWARD table. + + + + Use mark values > 255 for provider marks in this + column. These mark values must be a multiple of 256 in the + range 256-65280 (hex equivalent 0x100 - 0xFF00 with the + low-order 8 bits being zero). + + @@ -487,12 +506,14 @@ ip route add 192.168.1.1 dev eth3 scope link case ${priority%:} in 0|3276[67]) ;; - *) ip rule del $rule + *) + ip rule del $rule ;; esac done - That will delete all but the default routing rules. + That code will delete all but the default routing + rules.