diff --git a/STABLE/documentation/Accounting.html b/STABLE/documentation/Accounting.html index 52e5e772a..f64d954a0 100755 --- a/STABLE/documentation/Accounting.html +++ b/STABLE/documentation/Accounting.html @@ -27,69 +27,62 @@ Shorewall Traffic Accounting support was added in Shorewall release
Shorewall accounting rules are described in the file /etc/shorewall/accounting. By default, the accounting rules are placed -in a chain called "accounting" and can -thus be displayed using "shorewall show accounting". All traffic -passing into, out of or through the firewall traverses the accounting -chain including traffic that will later be rejected by interface options such as -"tcpflags" and "maclist". If your kernel doesn't support the connection -tracking match extension (Kernel 2.4.21) then some traffic rejected -under 'norfc1918' will not traverse the accounting chain.
+in a chain called "accounting" and can thus be displayed using +"shorewall show accounting". All traffic passing into, out of or +through the firewall traverses the accounting chain including traffic +that will later be rejected by interface +options such as "tcpflags" and "maclist". If your kernel doesn't +support the connection tracking match extension (Kernel 2.4.21) then +some traffic rejected under 'norfc1918' will not traverse the +accounting chain.

The columns in the accounting file are as follows:
-In all columns except ACTION and CHAIN, the values "-","any" and -"all" are treated as wild-cards.

+In all columns except ACTION and CHAIN, the values "-","any" and "all" +are treated as wild-cards.

The accounting rules are evaluated in the Netfilter 'filter' table. This is the same environment where the 'rules' file rules are evaluated and in this environment, DNAT has already occurred in inbound packets and SNAT has not yet occurred on outbound ones.


Accounting rules are not stateful -- each rule only handles traffic in one direction. For example, if eth0 is your internet interface and you -have a web -server in your DMZ connected to eth1 then to count HTTP traffic in -both directions requires two rules: 
+have a web server in your DMZ connected to eth1 then to count HTTP +traffic in both directions requires two rules: 
	#ACTION	CHAIN	SOURCE	DESTINATION	PROTOCOL	DEST		SOURCE
# PORT PORT
DONE - eth0 eth1 tcp 80
DONE - eth1 eth0 tcp - 80
Associating a counter with a chain allows for nice reporting. For example:
@@ -103,8 +96,16 @@ Here's a slightly different example:
Now "shorewall show web" simply gives you a breakdown by input and output:

-
[root@gateway shorewall]# shorewall show accounting web 
Shorewall-1.4.6-20030821 Chains accounting web at gateway.shorewall.net - Wed Aug 20 10:27:21 PDT 2003

Counters reset Wed Aug 20 10:24:33 PDT 2003

Chain accounting (3 references)
pkts bytes target prot opt in out source destination
8767 727K web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
11506 13M web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443
Chain web (4 references)
pkts bytes target prot opt in out source destination
8767 727K all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0
11506 13M all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0
[root@gateway shorewall]#

-

Last updated 8/20/2003 - [root@gateway shorewall]# shorewall show accounting web
Shorewall-1.4.6-20030821 Chains accounting web at gateway.shorewall.net - Wed Aug 20 10:27:21 PDT 2003

Counters reset Wed Aug 20 10:24:33 PDT 2003

Chain accounting (3 references)
pkts bytes target prot opt in out source destination
8767 727K web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
11506 13M web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443
Chain web (4 references)
pkts bytes target prot opt in out source destination
8767 727K all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0
11506 13M all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0
[root@gateway shorewall]#
+Here's how the same example would be constructed on a server with only +one interface (eth0):
+

#ACTION		CHAIN	SOURCE	DESTINATION	PROTOCOL	DEST		SOURCE
# PORT PORT
web - eth0 - tcp 80
web - - eth0 tcp - 80
web - eth0 - tcp 443
web - - eth0 tcp - 443

COUNT web eth0 -
COUNT web - eth0
+Note that with only one interface, only the SOURCE (for input rules) or +the DESTINATION (for output rules) is specified in each rule.
+
+Here's the output:
+
[root@mail shorewall]# shorewall show accounting web 
Shorewall-1.4.7 Chains accounting web at mail.shorewall.net - Sun Oct 12 10:27:21 PDT 2003

Counters reset Sat Oct 11 08:12:57 PDT 2003

Chain accounting (3 references)
pkts bytes target prot opt in out source destination
8767 727K web tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 web tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
11506 13M web tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 web tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443
Chain web (4 references)
pkts bytes target prot opt in out source destination
8767 727K all -- eth0 * 0.0.0.0/0 0.0.0.0/0
11506 13M all -- * eth0 0.0.0.0/0 0.0.0.0/0
[root@mail shorewall]#
+

Last updated 10/12/2003 - Tom Eastep

Copyright © 2003 Thomas M. Eastep.

diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index 21f87bed1..c255db080 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -173,7 +173,15 @@ only from specific IP Addresses on the internet?
options in nmap on or behind the firewall, I get "operation not permitted". How can I use nmap with Shorewall?"

-27. I am compiling a new kernel for my +26a.  When I try +to use the "-O" option of nmap +from the firewall system, I get "operation +not permitted". How to I allow this option?
+
+
27.
I am compiling a new kernel +for my firewall. What should I look out for?

28. How do I use Shorewall as a Bridging @@ -1079,13 +1087,22 @@ Shorewall I am running?
At the shell prompt, type:

/sbin/shorewall -version
+version
+

26. When I try to use any of the SYN options in nmap on or behind the firewall, I get "operation not permitted". How can I use nmap with Shorewall?"

Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes" then restart Shorewall.
+
+

26a.  +When I try to use the "-O" +option of nmap from the firewall system, I get "operation not permitted". How to I +allow this option?

+Add this command to your /etc/shorewall/start file:
+
run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP

27. I'm compiling a new kernel for my firewall. What should I look out for?

diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 2497af2f7..683de2cbe 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -19,6 +19,54 @@ +

10/21/2003 - Shorewall 1.4.7a
+

+

This is a bugfix rollup of the following problem corrections:
+

+
    +
  1. Tuomo Soini has supplied a correction to a problem that occurs +using some versions of 'ash'. The symptom is that "shorewall start" +fails with:

    +   local: --limit: bad variable name
    +   iptables v1.2.8: Couldn't load match +`-j':/lib/iptables/libipt_-j.so:
    +   cannot open shared object file: No such file or directory
    +   Try `iptables -h' or 'iptables --help' for more +information.
    +
    +
  2. +
  3. Andres Zhoglo has supplied a correction that avoids trying to use +the multiport match iptables facility on ICMP rules.

    +   Example of rule that previously caused "shorewall start" +to fail:

    +           +ACCEPT      loc  $FW  +icmp    0,8,11,12
    +
    +
  4. +
  5. Previously, if the following error message was issued, Shorewall +was left in an inconsistent state.

    +   Error: Unable to determine the routes routes through +interface xxx
    +
    +
  6. +
  7. Handling of the LOGUNCLEAN option in shorewall.conf has been +corrected.
  8. +
  9. In Shorewall 1.4.2, an optimization was added. This optimization +involved creating a chain named "<zone>_frwd" for most zones +defined using the /etc/shorewall/hosts file. It has since been +discovered that in many cases these new chains contain redundant rules +and that the "optimization" turns out to be less than optimal. The +implementation has now been corrected.
  10. +
  11. When the MARK value in a tcrules entry is followed by ":F" or +":P", the ":F" or ":P" was previously only applied to the first +Netfilter rule generated by the entry. It is now applied to all entries.
    +
  12. +

10/06/2003 - Shorewall 1.4.7

Problems Corrected since version 1.4.6 (Those in bold font were diff --git a/STABLE/documentation/PPTP.htm b/STABLE/documentation/PPTP.htm index aac549f73..df77ffc70 100644 --- a/STABLE/documentation/PPTP.htm +++ b/STABLE/documentation/PPTP.htm @@ -263,9 +263,15 @@ status)
esac

Configuring Shorewall

-

I consider hosts connected to my PPTP server to be just like local -systems. -My key Shorewall entries are:

+

Often there will be situations where you want multiple connections +from remote networks with these networks having different firewalling +requirements.
+

+

+
+

Here's how you configure this in Shorewall:
+

/etc/shorewall/zones:

@@ -283,7 +289,31 @@ My key Shorewall entries are:

- + + + + + + + + + + + + + + + +
loc LocalMy Local Network including remote PPTP clientsLocal Network
+
vpn1Remote1
+
Remote Network 1
+
vpn2
+
Remote2
+
Remote Network 2
+
vpn3
+
Remote3
+
Remote Network 3
+
@@ -307,13 +337,13 @@ My key Shorewall entries are:

loc eth2 - 192.168.1.255 + 192.168.10.255   - ppp+ -   +  -   @@ -335,145 +365,32 @@ My key Shorewall entries are:

- loc + vpn1
+ ppp+:192.168.1.0/24   - - -
-

/etc/shorewall/policy:

-
- - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG LEVEL
loclocACCEPT 
-
-

/etc/shorewall/rules (For Shorewall versions up to and including -1.3.9b):

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)
SOURCE
-PORT(S)
ORIGINAL
-DEST
ACCEPTnetfwtcp1723  
ACCEPTnetfw47-  
ACCEPTfwnet47-  
-
-

/etc/shoreawll/tunnels (For Shorewall versions -1.3.10 and -later)
-

-
- - - - - - - - - - - - - + + + +
TYPE
-
ZONE
-
GATEWAY
-
GATEWAY ZONE
-
pptpserver
+
vpn2
net
+
ppp+:192.168.2.0/24
0.0.0.0/0
+


+
vpn3
+
ppp+:192.168.3.0/24
+

-


-Note: I have multiple ppp interfaces on my firewall. If you have a -single -ppp interface, you probably want:

-

/etc/shorewall/interfaces:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
ZONEINTERFACEBROADCASTOPTIONS
neteth0206.124.146.255norfc1918
loceth2192.168.1.255 
locppp0  
-
-

and no entries in /etc/shorewall/hosts.

+Your policies and rules can now be configured using separate zones +(vpn1, vpn2, and vpn3) for the three remote network.

2. PPTP Server Running Behind your Firewall

@@ -968,7 +885,7 @@ as described in the QuickStart Guide corresponding to your setup.
That entry allows a PPTP tunnel to be established between your Shorewall system and the PPTP server in the modem.
-

Last modified 8/11/2003 - Tom +

Last modified 10/11/2003 - Tom Eastep

Copyright © 2001, 2002, 2003 Thomas M. Eastep.

diff --git a/STABLE/documentation/Shorewall_Doesnt.html b/STABLE/documentation/Shorewall_Doesnt.html index e96368499..ec6282d68 100644 --- a/STABLE/documentation/Shorewall_Doesnt.html +++ b/STABLE/documentation/Shorewall_Doesnt.html @@ -30,18 +30,28 @@ application.
  • Be used with an Operating System other than Linux (version >= 2.4.0)
  • -
  • Do content filtering -- better to use Squid for that.
  • +
  • Do content filtering:
  • + In addition:

    -Last updated 9/28/2003 - Tom +Last updated 10/07/2003 - Tom Eastep

    Copyright © 2001, 2002, 2003 Thomas M. Eastep.
    diff --git a/STABLE/documentation/Shorewall_Squid_Usage.html b/STABLE/documentation/Shorewall_Squid_Usage.html index 49b4ca3ea..0b23fb7ca 100644 --- a/STABLE/documentation/Shorewall_Squid_Usage.html +++ b/STABLE/documentation/Shorewall_Squid_Usage.html @@ -28,10 +28,14 @@
    This page covers Shorewall configuration to use with Squid running as a Transparent -Proxy. If you are running Shorewall 1.3, please see this documentation.
    + href="http://www.squid-cache.org/">Squid running as a Transparent +Proxy or as a Manual Proxy.

    +If you are running Shorewall 1.3, please see this documentation.
    +

    Squid as a Transparent Proxy
    +

    Caution     Please observe the following general requirements:
    @@ -71,7 +75,7 @@ running on the Firewall. local network
  • Squid running in the DMZ
  • -

    Squid Running on the Firewall

    +

    Squid (transparent) Running on the Firewall

    You want to redirect all local www connection requests EXCEPT those to your own http server (206.124.146.177) to a Squid transparent proxy running on the firewall @@ -123,15 +127,49 @@ DEST
    There may be a requirement to exclude additional destination hosts or networks from being redirected. For example, you might also want -requests destined for 130.252.100.0/24 to not be routed to Squid. In -that -case, you must add a manual rule in /etc/shorewall/start:
    +requests destined for 130.252.100.0/24 to not be routed to Squid.
    +
    +If you are running Shorewall version 1.4.5 or later, you may just add +the additional hosts/networks to the ORIGINAL DEST column in your +REDIRECT rule:
    +
    +
    + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    +PORT(S)
    SOURCE
    +PORT(S)
    ORIGINAL
    +DEST
    REDIRECTloc3128tcpwww -
    +
    !206.124.146.177,130.252.100.0/24
    +
    +
    +If you are running a Shorewall version earlier than 1.4.5, you must add +a manual rule in /etc/shorewall/start:
    run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN
     To exclude additional hosts or networks, just add additional similar rules.
    -

    Squid Running in the local network

    +

    Squid (transparent) Running in the local network

    You want to redirect all local www connection requests to a Squid transparent proxy running in your local zone at 192.168.1.3 and listening @@ -273,7 +311,8 @@ command above:
    color="#009900">
    chkconfig --level 35 iptables on
    -

    Squid Running in the DMZ (This is what I do)

    +

    Squid (transparent) Running in the DMZ (This is +what I do)

    You have a single Linux system in your DMZ with IP address 192.0.2.177. You want to run both a web server and Squid on that system. Your DMZ interface is eth1 and your local interface is eth2.
    @@ -455,7 +494,133 @@ command above:
    color="#009900">
    chkconfig --level 35 iptables on
    -

    Updated 8/9/2003 - Tom Eastep +

    Squid as a Manual Proxy

    +Assume that Squid is running in zone SZ and listening on port SP; all +web sites that are to be accessed through Squid are in the 'net' zone. +Then for each zone Z that needs access to the Squid server:
    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTION
    +
    SOURCE
    +
    DEST
    +
    PROTO
    +
    DEST
    +PORT(S)
    +
    CLIENT
    +PORT(2)
    +
    ORIGINAL
    +DEST
    +
    ACCEPT
    +
    Z
    +
    SZ
    +
    tcp
    +
    SP
    +

    +

    +
    ACCEPT
    +
    SZ
    +
    net
    +
    tcp
    +
    80
    +

    +

    +
    +
    +
    +Example:
    +
    +
    Squid on the firewall listening on port +8080 with access from the 'loc' zone:
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTION
    +
    SOURCE
    +
    DEST
    +
    PROTO
    +
    DEST
    +PORT(S)
    +
    CLIENT
    +PORT(2)
    +
    ORIGINAL
    +DEST
    +
    ACCEPT
    +
    loc
    +
    $FW
    +
    tcp
    +
    8080
    +

    +

    +
    ACCEPT
    +
    $FW
    +
    net
    +
    tcp
    +
    80
    +

    +

    +
    +
    +
    +

    Updated 1017/2003 - Tom +Eastep

    Copyright © 2003 Thomas M. Eastep.
    diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index 247361e6f..f0dee6e96 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -28,25 +28,25 @@ Issues

    If you use a Windows system to download a corrected script, be sure to run the script through dos2unix after you have moved -it to your Linux system.

    + style="text-decoration: none;"> dos2unix after you have moved it +to your Linux system.

  • If you are installing Shorewall for the first -time and plan to use the .tgz and install.sh script, you can untar -the archive, replace the 'firewall' script in the untarred directory -with the one you downloaded below, and then run install.sh.

    +time and plan to use the .tgz and install.sh script, you can untar the +archive, replace the 'firewall' script in the untarred directory with +the one you downloaded below, and then run install.sh.

  • When the instructions say to install a -corrected firewall script in /usr/share/shorewall/firewall, -you may rename the existing file before copying in the new file.

    +corrected firewall script in /usr/share/shorewall/firewall, you may +rename the existing file before copying in the new file.

  • DO NOT INSTALL CORRECTED COMPONENTS ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER -BELOW. For example, do NOT install the 1.3.9a firewall script -if you are running 1.3.7c.
    +BELOW. For example, do NOT install the 1.3.9a firewall script if you are +running 1.3.7c.

  • @@ -61,8 +61,7 @@ Version 1.1
  • Problem with iptables version 1.2.3 on RH7.2
  • Problems with kernels >= 2.4.18 and -RedHat -iptables
  • +RedHat iptables
  • Problems installing/upgrading RPM on SuSE
  • Problems with iptables version 1.2.7 and MULTIPORT=Yes
  • @@ -75,12 +74,35 @@ REJECT (also applies to 2.4.21-RC1)

    Problems in Version 1.4

    +

    1.4.7

    + +These problems have been corrected in this firewall +script which may be installed in /var/share/shorewall/firewall as +described above.

    1.4.6

    1.4.4b

    1.4.4
    @@ -147,8 +162,7 @@ described above.
    • If you have zone names that are 5 characters long, you may experience problems starting Shorewall because the --log-prefix in a -logging rule is too long. Upgrade to Version 1.4.4a to fix this -problem..
    • +logging rule is too long. Upgrade to Version 1.4.4a to fix this problem..

    1.4.3

    1.4.1a, 1.4.1 and 1.4.0

    @@ -190,8 +203,8 @@ in /etc/shorewall/common.def.
  • When a "shorewall check" command is executed, each "rule" produces the harmless additional message:

    -     /usr/share/shorewall/firewall: line 2174: [: =: -unary operator expected
    +     /usr/share/shorewall/firewall: line 2174: [: =: unary operator +expected

    You may correct the problem by installing 1.4.0
    +Shorewall allows you to start traffic shaping when Shorewall itself +starts or it allows you to bring up traffic shaping when you bring up +your interfaces.
    +
    +To start traffic shaping when Shorewall starts:
    +
      +
    1. Set TC_ENABLED=Yes and CLEAR_TC=Yes
    2. +
    3. Supply an /etc/shorewall/tcstart script to configure your traffic +shaping rules.
    4. +
    5. Optionally supply an /etc/shorewall/tcclear script to stop +traffic shaping. That is usually unnecessary.
    6. +
    7. If your tcstart script uses the 'fwmark' classifier, you can mark +packets using entries in /etc/shorewall/tcrules.
    8. +
    +To start traffic shaping when you bring up your network interfaces, you +will have to arrange for your traffic shaping configuration script to +be run at that time. How you do that is distribution dependent and will +not be covered here. You then should:
    +
      +
    1. Set TC_ENABLED=Yes and CLEAR_TC=No
    2. +
    3. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear +scripts.
    4. +
    5. If your tcstart script uses the 'fwmark' classifier, +you can mark packets using entries in /etc/shorewall/tcrules.
    6. +
    +

    Kernel Configuration

    +

    This screen shot show how I've configured QoS in my +Kernel:

    +

    +

    /etc/shorewall/tcrules

    +

    The fwmark classifier provides a convenient way to +classify packets for traffic shaping. The /etc/shorewall/tcrules file +provides a means for specifying these marks in a tabular fashion.
    +

    +

    Normally, packet marking occurs in the PREROUTING chain +before any address rewriting takes place. This makes it impossible to +mark inbound packets based on their destination address when SNAT or +Masquerading +are being used. Beginning with Shorewall 1.3.12, you can cause packet +marking to occur in the FORWARD chain by using the +MARK_IN_FORWARD_CHAIN +option in shorewall.conf.
    +

    +

    Columns in the file are as follows:

    + +

    Example 1 - All packets arriving on eth1 should be +marked with 1. All packets arriving on eth2 and eth3 should be marked +with 2. All packets originating on the firewall itself should be marked +with 3.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    1eth10.0.0.0/0all  
    2eth20.0.0.0/0all  
    2
    +
    eth3
    +
    0.0.0.0/0
    +
    all
    +

    +

    +
    3fw0.0.0.0/0all  
    +

    Example 2 - All GRE (protocol 47) packets not +originating on the firewall and destined for 155.186.235.151 should be +marked with 12.

    + + + + + + + + + + + + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    120.0.0.0/0155.186.235.15147  
    +

    Example 3 - All SSH packets originating in +192.168.1.0/24 and destined for 155.186.235.151 should be marked with +22.

    + + + + + + + + + + + + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    22192.168.1.0/24155.186.235.151tcp22 
    +

    My Current Setup
    +

    +

    I am currently using the HTB version of The Wonder Shaper (I just +copied wshaper.htb to /etc/shorewall/tcstart and modified it as +shown in the Wondershaper README). WonderShaper +DOES NOT USE THE +/etc/shorewall/tcrules file. While I currently have entries in +/etc/shorewall/tcrules, I do so for policy routing for Squid and not +for Traffic Shaping.

    +

    My Old Setup
    +

    +

    I have also run with the following set of hand-crafted rules in my /etc/shorewall/tcstart +file.
    +

    +
    +
    run_tc qdisc add dev eth0 root handle 1: htb default 30

    run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

    echo "   Added Top Level Class -- rate 384kbit"
    +
    run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
    run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
    run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1
    +
    echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
    +
    run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
    run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
    run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
    +
    echo "   Enabled PFIFO on Second Level Classes"
    +
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
    +
    echo "   Defined fwmark filters"
    +
    +

    My tcrules file that went with this tcstart file is shown in Example +1 above. When I was using these rules:
    +

    +
      +
    1. I wanted to allow up to 140kbits/second for traffic outbound from +my DMZ (eth1 -- note that the ceiling is set to 384kbit so outbound DMZ +traffic can use all available bandwidth if there is no traffic from the +local systems or from my laptop or firewall).
    2. +
    3. My laptop (which at that time connected via eth3) and local +systems (eth2) could use up to 224kbits/second.
    4. +
    5. My firewall could use up to 20kbits/second.
    6. +
    +Once www.shorewall.net was moved off-site, I no longer needed these +shaping rules and The Wonder Shaper does all that I now require.
    +

    Last Updated 10/21/2003 - Tom +Eastep

    +

    Copyright2001, 2002, 2003 Thomas M. Eastep.
    +

    +
    +
    +
    +
    +
    +
    diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index d008a31e1..a04468d5c 100755 --- a/STABLE/fallback.sh +++ b/STABLE/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.4.7 +VERSION=1.4.7a usage() # $1 = exit status { diff --git a/STABLE/install.sh b/STABLE/install.sh index 9a2c1145a..4edffed39 100755 --- a/STABLE/install.sh +++ b/STABLE/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.4.7 +VERSION=1.4.7a usage() # $1 = exit status { diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index 4d4cac0b4..a4e21f8d2 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.4.7 +%define version 1.4.7a %define release 1 %define prefix /usr @@ -108,6 +108,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Tue Oct 21 2003 Tom Eastep +- Changed version to 1.4.7a-1 * Sat Oct 04 2003 Tom Eastep - Changed version to 1.4.7-1 - Removed conflict with 2.2 Kernels diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index ca54b3929..6f896635e 100755 --- a/STABLE/uninstall.sh +++ b/STABLE/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=1.4.7 +VERSION=1.4.7a usage() # $1 = exit status {