User talk:Firestormer

Windows 2000 Domain

http://www.washington.edu/computing/support/windows/UWdomains/domainsAndForests.html

The University of Washington has both independent forests as well as a central forest. In addition, C&C offers a managed Windows domain service called Nebula. Below you'll find an introduction, history, an explanation of the Windows Domain DNS reliance, firewall gotchas, detailed info about the central forest, and a document that describes how to setup a new Windows domain.

Introduction With the advent of Windows 2000, Microsoft introduced the concept of multiple Windows domains sharing a common source for authentication and authorization in a forest. This common source of authentication and authorization is usually referred to as Active Directory. This information is distributed across many domain controllers, and a subset of all the information is stored centrally on special domain controllers called global catalogs. Computers and users in a forest can easily share file, printer, and other resources. In addition, Microsoft wedded the Windows domain concept to DNS. Prior to this, Windows domains only used Netbios for name resolution. With this change, every Windows 2000 or later domain must correspond to a DNS zone, and each domain controller requires specific DNS records in order to operationally function. This change meant that a Windows domain service could finally be resolved globally.

History C&C lead an effort to deploy a shared forest, called the UW forest. This forest is a loose confederation of domains with no special integration with other computing infrastructure (aside from DNS), and was a valid design at its inception. However, early in 2002 Microsoft announced a vulnerability which changed their stated assumptions about the security boundaries. Prior to this, the domain was a clear security boundary. With this announcement, it was clear that the forest was the security boundary. In other words, a domain admin in one domain might be able to impersonate a domain admin in another domain. For this reason, C&C began actively discouraging further implementation in the UW forest. In addition, a number of security related policies were implemented to minimize the risk via this vulnerability. If you don't have a Windows domain and would like to setup a new one, we recommend that you create an independent forest. If you need to share Windows resources with a department that is in the UW forest, you can setup a domain trust with the specific domain to meet this business need.

Understanding the Windows Domain DNS reliance Windows domains now require a fully qualified domain name (FQDN) to support ldap, kerberos, PKI certificates, and other new technologies which are now integrated with the operating system. For this reason, Windows domain controllers must have a FQDN within the FQDN of the Windows domain. So if my Windows domain name is joe.washington.edu, then my domain controllers must have a FQDN of myDCname.joe.washington.edu. Only Windows domain controllers have this restriction; the Windows workstation with the DNS name of myWorkstation.microsoft.com can join the joe.washington.edu Windows domain. Windows domain controllers hold authentication and directory services. Domain controllers must register roughly a dozen special DNS records called SRV records to provide name resolution for authentication and directory services. Without these records login and most domain services would break. These SRV records may be registered statically or via DDNS. SRV records are supported by DNS BIND 4.96 or higher, and DDNS is supported by DNS BIND 8.12 or higher. The campus DNS servers don't current support dynamic DNS, but this functionality is being investigated.

Because of the existing lack of DDNS support, you need to send DNS updates to the NOC when you first bring up a domain controller and every time the IP address changes. This is done simply by sending the netlogon.dns file. The netlogon.dns file is commonly located at %windir%\system32\config\netlogon.dns.

In addition to these SRV records, you must also have an A record for each domain controller. Microsoft also recommends that you have an A record for the Windows domain's FQDN. This final A record provides the "glue" for non-Microsoft clients which won't know how to find domain services otherwise.

If you are running a split-DNS in conjunction with a NAT, you need to make sure that these DNS records resolve correctly from both sides of the NAT.

If you are running a non-authoritative DNS server, you might want to think again. Microsoft doesn't support this option.

See the following document for further reading:

Windows 2000 DNS White Paper Understanding the implications of a Firewall Implementing a firewall in front of Windows domain controllers can cause a lot more problems than it solves. This is especially true in a shared forest where you'd need to open up most of the Microsoft ports in order to allow basic forest communication to function. There is an excellent Microsoft whitepaper which addresses this topic: Active Directory in Networks Segmented by Firewalls An alternative is to put Windows Domain Controllers in the UW Project 172 limited access network. Windows 2000 Domains at the UW Computing & Communications Setting up Windows 2000® Domains and Forests in the UW network environment Modified October 10, 2003 Table of Contents •	Introduction •	Purpose of this document •	A note about the term "domain" •	Chapter 1: Requirements •	Authority to run the domain controllers for your intended DNS domain •	Windows 2000 Servers installed as a stand alone servers •	A static IP address and DNS name assigned to your intended DCs •	Chapter 2: Setting Up Your Domain •	Authorize your domain •	Register your domain controllers •	Chapter 3: Setting up the domain controllers •	Run DCPROMO •	Send DNS information to Network Operations •	Turn Off Dynamic DNS •	Configure a time server •	Chapter 4: Removing a domain controller •	Chapter 5: Where to go from here

Introduction

Purpose of this document This document is intended for support personnel or system administrators at the University of Washington. It covers setting up a Windows 2000 domain controller that will be linked into the UW's existing DNS structure. This document does not cover the details of setting up and using Windows 2000; it assumes that you are already familiar with the basics of using Windows 2000. A note about the term "domain"

Throughout this document the word domain will sometimes refer to a DNS domain and sometimes refer to a Microsoft Windows domain. While in the past these two concepts were separate and non-interchangeable, that is not as true today. With Windows 2000, Microsoft has adopted the DNS naming conventions and structures to its domains. For example, the domain name "cac.washington.edu" is both the DNS and Windows 2000 domain name for Computing and Communications. For most purposes, these terms are now interchangeable.

Chapter 1: Requirements The following chapters of this document assume that you have already performed certain requirements. Those requirements and how to get more help in fulfilling them are outlined below.

Authority to run the domain controllers for your intended DNS domain In Windows 2000, the windows domain naming structure parallels the DNS naming structure. Thus, the authority and responsibility for the DNS and windows domains are one and the same. If you are unaware of the contact for your department's DNS domain, wish to change the contact person for your department, or wish to register a new department, send email to netops@cac.washington.edu or call Network Operations at 543-5128. Windows 2000 Servers installed as a stand alone servers You should have at least two servers ready to act as domain controllers. These machines should not be used as workstations or provide other network services since their stability and availability are paramount. The reason for having more than one domain controller is that if all of your domain controllers become simultaneously unavailable, users cannot log in to your domain. Additionally, if all of your domain controllers become simultaneously unrecoverable, your domain will have to be recreated from scratch. If you intend to create your domain in the UW forest, having at least two domain controllers is a strict requirement.

The domain controllers do not have to have a great deal of computing horsepower. Two domain controllers, each with a PIII 450 CPU, 512MB of RAM and a 20GB hard drive will be more than adequate for typical domains serving around a hundred users provided they are only acting as domain controllers. It is easy to add and/or upgrade domain controllers in the future should you find that you require more capacity. A static IP address and DNS name assigned to your intended DCs Since your domain controllers must be found by workstations wishing to log into your domain, they must be registered with static IP addresses and have a DNS name in your intended domain. If you require a new or a modification to a DNS registration, send email to netops@cac.washington.edu or call Network Operations at 543-5128.

Chapter 2: Setting Up Your Domain

Authorize your domain In order to maintain the domain controllers for a domain, you must be the domain contact person. Every existing DNS domain already has a contact person listed. If you are unsure of your domain contact person, you can contact Network Operations to find this out. If you are the domain contact, you can contact Network Operations to request that your domain controller servers be registered as such so that other computers can find them. This process is outlined below.

If you have questions about the DNS domain contact system, you can reach Network Operations at 543-5128 or send email to netops@cac.washington.edu. Register your domain controllers

Send email to win2kinfo@cac.washington.edu with the following information: •	The name of your DNS domain •	The full DNS names of your intended domain controllers (there should be at least 2) •	If you intend to join this domain to the UW forest. •	Are you planning to upgrade an existing NT 4 domain or create a new domain? •	Your timeline for the upgrade or installation •	Do you have trusts to other domains? •	The number of users in your domain Example: From: Jane Smith  To: win2kinfo@cac.washington.edu Subject: New Windows 2000 domain Hi, I'm Jane Smith, the domain contact for xyz.washington.edu. I would like to register: bert.xyz.washington.edu and ernie.xyz.washington.edu as     Windows 2000 domain controllers for my domain. I will be upgrading an existing NT 4 domain, which is     used by approximately 50 people. I'd like to join this domain to the UW forest. I do not have trust relationships with any other domains. I'd like to make the transition to Windows 2000 around the first of     September. Thanks, Jane Smith You will shortly get back a reply that those machines are OK to use as the domain controllers and a FAQ outlining the UW's campus-wide domain forest. You should then decide if you want to join your domain to the campus forest. If you decide to join the UW campus forest, you will need set up an appointment with a C&C representative to set up your domain controllers and join your domain to the forest. You do not need to continue with this document. An appointment is necessary because when you first join the forest, the administrator of the forest has to perform the join operation. You will not need the forest administrator to set up subsequent domain controllers, server, or workstations in that domain. If you decide not to join the UW campus forest, or are not setting up the first domain controller in your domain, continue with these instructions. Chapter 3: Setting up the domain controllers For each of your domain controllers, you should follow the steps in this chapter. Some steps will have alternate actions depending on if you are joining an existing forest. Run DCPROMO From the Start menu of your domain controller, select run and enter: DCPROMO This will start the Active Directory Installation Wizard. If this is the first domain controller in your domain, choose "Domain controller for a new domain". If this is not the first one you have set up, choose "Additional domain controller for an existing domain, click next, and authenticate to your existing domain. Choose "Create new domain tree", even if you will be joining an existing forest. If you are joining an existing forest, choose "Place this new domain tree in an existing forest". Otherwise, choose "Create a new forest of domain trees". If you are joining an existing forest, you will be asked for credentials to use to join.  You will need to get this information from the administrator of the forest you are joining.  This account must have authority to add domains to the forest. Enter the name of your domain. Specify a NetBIOS name for your new domain.  This name will be used by older operating systems (Windows 98, NT 4.0, etc.) should you choose to support those operating systems. If you have separate physical hard disks, it's a good idea to keep the database and log on separate disks. Otherwise, one could slow the other down. Enter a directory for the public files area of your Active Directory tree. At this point, you may see the following message. You can safely ignore this, as you will be sending DNS registration information in a later step. Choose No, you will be configuring this later. Unless you have a mixed environment with Windows NT 4.0 servers that use Active Directory information, you should choose to set the more strict Windows 2000 only permissions. Enter a password to be used if you must restore the Active Directory. This will also be your initial administrator password. Review your setup and click next to start the configuration process. You will see a screen similar to the following for a few minutes. When the configuration process completes, you will be directed to restart your computer. After your domain controller restarts, log in to your new domain as administrator.

Send DNS information to Network Operations Find the file NETLOGON.DNS from your domain controller's \SYSTEM32\CONFIG directory.  will usually be C:\WINNT.

Attach this file in an email message to netops@cac.washington.eduwith a subject or short message of: DNS entries for Windows 2000 domain xyz.washington.edu. (Use your own domain here of course). Do not edit the file or import it into the body of the message. Attach it to the message using a MIME compatible mailer such as Outlook Express or pine. If you are setting up multiple domain controllers, you can send them all as attachments to one message. You will shortly receive an email that this information has been entered into the UW's DNS servers. If this is a change to an existing Windows 2000 domain, it can take up to 24 hours for the old information to be overwritten. Otherwise, your new domain is ready for use as soon as you complete the next section.

Turn Off Dynamic DNS By default, a Windows 2000 or 2003 domain controller will try to periodically update its DNS server with new information. Since the DNS servers at the UW do not accept dynamic updates, this will cause unnecessary network traffic and trigger error events in your event logs.

To turn off dynamic DNS updates on a domain controller: You should disable (uncheck) the "Register this connection's addresses in DNS" setting. This property can be found in the DNS tab of the Advanced TCP/IP Settings dialog in the properties of your local area network connection.

This should be done on every network interface for the domain controller. If you would like information on how to turn off DNS updates on your workstations using group policy objects, see Microsoft Knowledge Base article Q294832. If you are not using the UW's DNS servers and are running your own DNS servers that support dynamic updates, you can disregard this section.

Configure a time server Since Windows 2000 uses Kerberos authentication, having the correct time is critical. If this is the first domain controller you are setting up, you must give it an external time source as follows: 1.	Open a command shell as administrator 2.	Enter: net time /setsntp:time.u.washington.edu Chapter 4: Removing a domain controller If you wish to remove a domain controller from an existing doman, follow these steps. NOTE: If you remove the last remaining domain controller for a domain, all Active Directory information from that domain will be permanently lost. In addition, removing the last domain controller from a domain requires Enterprise Administrator privileges. If this domain is part of the UW forest, this means you will need to schedule the removal through win2kinfo@cac.washington.edu 3.	Click Start, click Run , type dcpromo , and then click OK. 4.	This starts the Active Directory Installation Wizard. Click Next. 5.	There is a check box in the Remove Active Directory screen. If this computer is the last domain controller in the domain, click to select the check box. Otherwise, click Next. 6.	In the next screen, set the password for the administrator account on the server after Active Directory is removed. Type the appropriate password in the Password and Confirm Password boxes, and then click Next. 7.	In the Summary screen, review and confirm the options you selected, and then click Next. 8.	The wizard begins the process of removing Active Directory from the server. After the process is finished, a message indicates that Active Directory was removed from the computer. 9.	Click Finish to quit the wizard. 10.	Restart the computer. 11.	Send an email message to netops@cac.washington.edufrom your DNS domain contact with a short message of: Please remove all SRV and CNAME records for dcserver1.xyz.washington.edu (Use your own DC and domain here of course). It can take up to 24 hours for the old information to be overwritten. During this time you may see some errors as clients and servers try to contact the demoted domain controller.

Chapter 5: Where to go from here There is documentation available for Windows 2000 at the UW. There is also a great deal of documentation available from Microsoft on Windows 2000 in general. For help with a Windows 2000 domain that you administer, please send your query to win2kinfo@u.washington.edu. For general help with Windows 2000 at the UW, please send mail to help@cac.washington.edu. Please note that C&C can only provide support for the services that it offers and can only respond to specific questions. If you require in-depth consulting, such as NT migration planning, please contact Client Services Project Consulting to set up a for fee consulting service.

The m0n0wall Traffic Shaper
To: , From: "David Kitchens"  Subject: RE: [m0n0wall] Help/Documentation with Traffic Shaper Date: Mon, 19 Apr 2004 22:47:24 -0400

The m0n0wall Traffic Shaper

by

Adam Nellemann

http://m0n0.ch/wall/list/?action=show_msg&actionargs%5B%5D=49&actionargs%5B%5D=99

Preparation As it is (perhaps?) possible (if not very likely) to break you firewall configuration (at least to the extent of making the webGUI inaccessible from your current host) by misconfiguring the traffic shaper, I strongly recommend that you make a local backup of your config file and ensure you have some means of restoring it in case you suddenly can't access the webGUI. In all fairness it should be said that I've never succeeded in making the traffic shaper doing anything that prevented me from accessing the webGUI myself or otherwise made anything go broken in m0n0wall, with the possible exception of slowing down my network a bit during some of my (mis)configuration attempts!)

Like when making firewall rules, having a good set of aliases, including some network aliases for the various subnets and IP pools used, will make it much easier to maintain the shaper configuration (and, in some cases, allow you to use a single rule instead of several, by clever use of network aliases to denote a contiguous group of IPs on a subnet boundary. See my examples below for how this can be achieved.)

General There are (obviously) three parts to the shaper: Rules, queues and pipes.

The rules are the "brain" of the shaper; they work much like the firewall rules, except instead of passing or blocking they select where the packets go: Either directly to a pipe, or through a queue which in turn pass it on to its associated pipe.

Queues, the "shaper police", are wedged between the rules and the pipes; they hold packets in an orderly fashion until the associated pipe is ready to accept more data, while also sharing the bandwidth of the pipe according to the different queue "Weights" (if any).

Pipes are the bottom layer of the shaper, the "plumbing" if you will pardon the pun; they simply limit the maximum bandwidth used by, as well as optionally introducing a fixed delay for, all packets passing through them.

Note: Since the traffic shaper introduces a number of extra "layers" in the way m0n0wall process its packets, a slightly higher latency might be a result of enabling the shaper. In addition to this, the various limitations on pipes and queues will further reduce bandwidth and/or increase latencies. This is to be expected, and will in most cases be more than made up for by the increased throughput achieved with proper traffic shaping.

I find the logical way to tackle the three parts of the shaper is with a bottom-up approach, starting with the pipes, going on to the queues and finishing with the rules. This goes for understanding the shaper, as well as for building your shaper configuration, thus I have chosen this order for my description of the three parts below.

Pipes When creating a pipe, the most important property you specify is its "Bandwidth" (or more precisely, its "Bandwidth limit"). This determines the maximum "flowrate" of traffic going through the pipe. If more traffic is trying to get through, the pipe will start holding back the packets (exactly how it does this I don't know, except if the packets are in a queue, in which case they will simply stay there until the pipe is ready for more traffic. I must assume that each pipe has its own "internal" queue, in case packets are sent directly to it?)

Rules of thumb regarding the use of bandwidth:

- Ensure that the total bandwidth of all pipes (including the expected number of "virtual" pipes) NEVER exceed your actual (real-world) bandwidth (preferably as tested by some reliable speed-test, rather than calculated from the stated bandwidth of your ISP. If not possible to test reliably, subtract at least 10% of the stated bandwidth.)

Aside from the bandwidth, a pipe can have a "Delay", simulating a high-latency connection. While I'm not sure about how this is implemented, I'm guessing that only one package is sent through the pipe during each interval, which would mean that if 10 ms is specified, only 100 packets will get through each second. However, it might instead be that each package is simply delayed for the specified interval, in which case any number of packets can go through each second, but only after waiting for the specified number of milliseconds.

Rules of thumb regarding the use of delay:

- Don't! Unless you really want to severely limit the speed of certain packets, and even so this is probably mainly effective in the outbound direction, as delaying inbound packets when they reach your firewall will typically just cause a backlog at the ISP, preventing the shaper from working properly.

Finally the pipe can have a "Mask", used to determine when to create "virtual pipes". The way this works is that for each host IP matching the mask (either source or destination), a virtual pipe is created. This can be used for splitting the available bandwidth statically between hosts. For instance, a pipe accepting outbound traffic (as determined by some rules) without any mask, will cause the local hosts to share the bandwidth of the pipe for all outbound traffic going through this pipe (total bandwidth = bandwidth of pipe). If source is specified for the mask, each local host will get their own (virtual) pipe and thus each get the specified bandwidth (total bandwidth = bandwidth of pipe x local hosts). Of couse one could also specify a destination mask, in which case the (outbound) pipe would create a virtual pipe for each destination host on the WAN (probably not a good idea).

The last example above shows how important it is to get the mask right, if using these. Remember that the "direction" of traffic is determined not only by the "Direction" of the rules, but also by which interface to which the rules apply (ie. the same package could first be inbound on LAN then outbound on WAN) so when moving rules from one interface to another, you will typically need to swap the mask (if specified).

Rules of thumb regarding the use of mask:

- Typically used only when you want a static split of bandwidth between a number of (source or destination) hosts.

- Depending on which interface your users come from, you will typically want to set up the masks in such a way as to always select on either remote or local hosts (assuming what you want is to give each user a certain fraction of your total bandwidth).

Some pipe examples (relating to the pipe and rule examples further below):

(No: Bandwidth,   Delay,        Mask, Description)

1: 232 Kbit/s,  [blank],     [blank], "<= ADSL Full" 2: 992 Kbit/s,  [blank],     [blank], "=> ADSL Full"

These two pipes is what I use for all my WAN traffic (which is through a 1024/256 Kbit/s ADSL modem). Note that my ISP has a very "friendly" definition of the speed provided (I suspect they aim to provide the stated speeds AFTER any overhead has been disregarded), normally you would probably need to lower the bandwidths even further!

3:  64 Kbit/s,     2 ms,      Source, "<= ADSL Limited" 4: 256 Kbit/s,  [blank], Destination, "=> ADSL Limited"

I use these pipes for my WLAN "guests", they are masked so each local host will get its own pipe (ie. static bandwidth sharing). Notice how I use source for the outbound pipe and destination for the inbound, this is because I want a virtual pipe created for each local host. Since my rules will be working on the WAN interface, the local host will be the source for outbound and the destination for inbound packets (if the rules were to be on another interface, or if I wanted to create virtual pipes for each remote host, the masks would have to be swapped.)

As an experiment, I've assigned a small delay to the outbound pipe, in an attempt at limiting the number of requests for inbound traffic (which I guess will only work as intended if I'm right about how the delay is implemented above!)

5: 2048 Kbit/s, [blank],     [blank], "<=> Intranet"

This last pipe is used for intranet traffic, which in my case consists mainly of jobs to my print server. Since I'm using a 802.11b wireless LAN, I'm using this pipe to limit the local traffic so as to keep some bandwidth reserved for packets to or from the WAN.

Queues While I guess a queue has an effect merely by existing (and being used of course), they really come into their right when you assign a different "Weight" to a number of queues using the same pipe (at least I think the latter is a requirement?) In this case the queues are prioritised in such a manner that the queue with the highest weight get more of the pipes bandwidth (while always ensuring that all queues get their share, even if a queue with a higher weight has packets waiting, thus the use of "weight" rather than "priority").

Rules of thumb regarding the use of weight:

- Remember these are relative "ratios", that is a 20 queue should get twice the bandwidth in relation to a 10 queue, but since this number isn't a strictly a priority, even if the 20 queue has a large number of packets waiting the 10 queue should still get its third of the bandwidth.

- Don't expect the ratio to be precisely reflected in the traffic flow. Experimentation is the only way I've found, that will tell you what you get with different weights.

Like pipes, queues can have a mask. The same logic as for pipes, applies to how "virtual" queues are created based on this mask. While there might be other sensible possibilities, it is my experience that a queue should typically have the same mask setting as its associated pipe, and in many cases the queue should have no mask, even if the pipe has one. I assume the only reason for giving a queue a mask, would be to give each host a separate queue as well as a separate pipe, in a static bandwidth splitting scenario, making traffic for each host entirely independent of traffic from the others.

Rules of thumb regarding the use of mask:

- (see pipes).

- Ensure that the mask of a queue (if any) matches that of the pipe (if any) it is using.

Note: Since it is possibly to specify a rule that send packets directly to the pipe, bypassing the queues altogether, there is effectively always an extra "high priority" queue available. I guess caution should be exercised when sending packets directly to a pipe, as too much traffic in this manner will probably put the queues on permanent hold? It should however, be an efficient way to get certain small, low volume packets (such as ACK, SYN and DNS) through the shaper as quickly as possible.

Some queue examples (relating to the pipe and rule examples further above and below):

(Num: Pipe, Weight,   Mask, Description)

1:      1,     96, [blank], "<= High" 2:      1,     32, [blank], "<= Medium" 3:      1,      2, [blank], "<= Low"

These are my three outbound queues, they all use the same pipe but with different weights for prioritising different traffic (ie. dynamic bandwidth sharing).

4:      2,     96, [blank], "=> High" 5:      2,     32, [blank], "=> Medium" 6:      2,      2, [blank], "=> Low"

These are the three inbound queues, as above but for the other direction.

7:      3,      4, [blank], "<= Limited" 8:      4,      4, [blank], "=> Limited"

These are the queues used by my "guests", going to the two limited and masked pipes. While I'm not sure the weight will have anything to say since these queues go to separate pipes, I've made sure to give them appropriate values just in case. Also, you would typically specify a source respectively destination mask for queue 7 respectively 8, since the related pipes are masked this way, but as I have so few "guests" which I mainly want to prevent from stealing too much bandwidth altogether, I've chosen to use a global queue instead of separate virtual ones, minimizing the strain on m0n0wall.

Rules As mentioned the shaper rules are a bit like those used for the firewall, specifically the interface, protocol, source, destination and port ranges are the same. In addition to this, you can also specify a direction (relative to the chosen interface), a packet size (or size range) and a number of TCP flags that must or mustn't be present in the packet, all used to further refining the match criteria. Finally each rule has a "Target", which can either be a pipe or a queue, to which any matching packets are passed. Like with firewall rules, the order of the shaper rules is relevant, as a packet will be checked against the rules from the top down, and the first one matching will be used to decide which pipe or queue the packet is sent to. I guess the rule list could have been separated into separate lists for each interface like the firewall rules, but this is not the case (currently anyway, I don't know if this is something Manuel plans to do in a future release?)

Making these rules is much like making rules for the firewall, with some exceptions: The interface is typically WAN, as it is mainly the connection to the outside net that need to be shaped (although there are scenarios where inter-LAN or LAN<->OPTx packets will need shaping as well, one example could be to limit the LAN<->DMZ traffic, in order to ensure free bandwidth for the WAN<->DMZ traffic, or advanced "double shaping" combining static and dynamic shaping on two interfaces). Also a shaper rule has a "Direction" (in, out or any), which is used to split traffic between inbound and outbound pipes and queues, either to ensure proper masking of these, or because of asymmetrical WAN bandwidths. Finally you can optionally specify a packet size (or size range) and a number of flags that need to be on or off in the packet. The flags are used to narrow the matching criteria even further depending on certain flags being on or off, and are mainly used for special cases, like ACK or SYN packets. Size limitation can be used when bypassing the queues, to prevent large ACK packets (ie. combined ACK and data packets) from filling the pipe and thus blocking the queues, or in other cases where packets below or above a given size need to be handled separately etc.

Rules of thumb regarding shaper rules:

- Unless you have special needs and/or know what your are doing, always make your shaper rules work on the WAN interface.

- Make sure that the source, destination of a given rule corresponds to both its direction, as well as the mask(s) on the queue and/or pipe specified for the rule.

Some rule examples (relating to the pipe and queue examples further above):

(IF, Dir, Proto, Src/port(s), Dest/port(s),  Length,        Flags,  Target, Description)

LAN, any, any, IntraNet/any, IntraNet/any, [blank], [don't care],  Pipe 5, "LAN <=> WLAN" WLAN, any, any, IntraNet/any, IntraNet/any, [blank], [don't care],  Pipe 5, "WLAN <=> LAN"

These rules are for limiting my LAN <=> WLAN traffic (mainly to ensure that some wireless bandwidth are reserved for traffic to the WAN interface). Notice that I have not used a queue for this traffic. As I assume there will seldom be a backlog / congestion on the intranet, I might as well save m0n0wall the trouble (not that my current platform lacks RAM or CPU power, but for Soekris users this might be of some importance!) Also there isn't anything else going through these particular pipes, making the use of a queue somewhat (if not entirely) moot. (As previously mentioned, I have yet to completely figure out the difference between going through a queue and going directly to the pipe, in cases where only one queue is present for the pipe. Thus I really can't say if this is the right way to do it or not?)

"IntraNet" is my alias for the x.x.32.0/23 subnet encompassing the WLAN (x.x.32.0/24) and LAN (x.x.33.0/24) subnets. This is a way to avoid having a similar set of rules for each subnet (the same trick can be used for DHCP pools or other contigous IP ranges, if made to fit with a subnet size and boundary). WLAN is my OPT1 interface, used as wireless AP in m0n0wall.

WAN, out, TCP,  PrioNet/any,        */any,   0-128,      ACK set,  Pipe 1, "<= ACK" WAN, in,  TCP,        */any,  PrioNet/any,   0-128,      ACK set,  Pipe 2, "=> ACK"

These rules are used to ensure swift transfer of small ACKs in both directions (notice that these are sent straight to the pipe instead of through a queue). I have a similar set of rules for SYNs (with SYN flag instead of ACK, and size = 0-512), and for DNS (no flags, size = 0-512, source/destination port = 53, with an extra set of rules for UDP, since I'm not sure which protocol is used for DNS if not both?) These rules are all limited to my own hosts.

"PrioNet" is an alias for a small subnet (x.x.32.128/30), encompassing the (static) IPs assigned to my hosts on the WLAN (the same trick as with the "IntraNet" alias above, used here to avoid having to specify all the rules, relating to the "priority" hosts, four times each!)

WAN, out, TCP,   PrioNet/25,        any/*, [blank], [don't care], Queue 1, "<= SMTP" WAN, in,  TCP,        */any,  PrioNet/143, [blank], [don't care], Queue 4, "=> IMAP"

These rules are for mail traffic (SMTP out and IMAP in in this case) to and from my own hosts. This traffic is passed to the high priority queue, to ensure mail will get preference over any other kind of traffic (with the exception of the ACK, SYN and DNS packets). I have similar rules for HTTPS (port = 443 in both directions).

WAN, out, TCP,  myhost/p2pp,        any/*, [blank], [don't care], Queue 3, "<= P2P (clients)" WAN, in,  TCP,        */any,  myhost/p2pp, [blank], [don't care], Queue 6, "=> P2P (clients)"

These rules are for my peer-to-peer program (the actual port numbers as well as the name of my p2p program have been removed to protect the "innocent"). I pass this traffic to the low priority queue, to ensure that anything else gets preference over the p2p traffic. Doing it this way, with a queue with low weight going to the same pipe as my other traffic instead of using a separate pipe, allow my p2p program to use all available bandwidth, while forcing it to release a certain fraction of it when needed for other traffic (making it possible to have a decent web-browsing experience without limiting my p2p more than necessary.)

WAN, out, any,  PrioNet/any,        */any, [blank], [don't care], Queue 2, "<= Other Prio traffic" WAN, in,  any,        */any,  PrioNet/any, [blank], [don't care], Queue 5, "=> Other Prio traffic"

These rules are "catch alls" for any traffic not matched by the rules above, but going to or from the priority hosts. This is passed to the medium priority queue, giving it preference over p2p but below the high priority stuff in the rules above.

WAN, out, any,        */any,        */any, [blank], [don't care], Queue 7, "<= Other Prio traffic" WAN, in,  any,        */any,        */any, [blank], [don't care], Queue 8, "=> Other Prio traffic"

These rules match anything that isn't already caught by the other rules, assuming this will be traffic from guest hosts to the WAN. This traffic is passed to the limited queues, which in turn pass it to the limited and masked pipes (which, as mentioned, will provide a static bandwidth allocation for each of these hosts).

Additional information

A packets way through the traffic shaper:

IF(in) => [matching rule] => [queue] => [pipe] => IF(out)

or:

IF(in) => [matching rule] => [pipe] => IF(out)

or:

IF(in) => [no match!] => IF(out)

Note that the last possibility will effectively bypass the traffic shaper (while still adding the overhead of checking the packet(s) against all shaper rules). It is therefore important to ensure that all possible packets will be match by at least one rule. Unlike the firewall, the shaper has no default "catch all" rule (except, as indicated above, sending the packet on to its destination interface). Even if some traffic doesn't need to be shaped, as long as it passes through an interface that is otherwise being shaped, it is wise to make a rule for it (and perhaps a pipe and/or a queue to send it through as well). This way there is no chance for this "unshaped" traffic to flood the interface and prevent the shaper from operating as intended.

While I have mentioned it before, it is very important to understand the issue about not using too high bandwidth(s) in the shaper and/or allowing traffic to "slip through" the shaper rules. There is no magic built into the shaper, it will only be able to perform its tasks if it remains the single point of limitation along the path from source to destination. This means you need to prevent your WAN equipment (both the modem or whatever on your side and whatever equipment is on your ISPs side) from queuing your traffic. If this happens, the shaper will no longer have any control over the queue, and is thus effectively "out of the game".

This is why you need to ensure that the total bandwidth through all pipes (remembering to include any "virtual" ones created by masking) taken together, is safely below your actual bandwidth. Knowing the precise number of virtual pipes or queues created can be difficult, not to say impossible, especially in larger networks with a lot of DHCP hosts or scenarios with a lot of hosts on the WAN side. In such cases a fair guess (preferably erring on the slightly larger side) will have to be used, possibly in conjunction with "double shaping", as in: Shaping the total traffic, with a single pipe limiting the maximum bandwidth on one interface, then shaping once again on the other interface, this time with masked pipes/queues making the static bandwidth split. This way, even if [number of hosts] times [bandwidth allocated for each host] exceeds your total bandwidth, the total traffic shaping prevents this from flooding any queues not controlled by m0n0walls shaper. (I haste to say that I've not tried such "double shaping" myself, thus this is purely conjecture on my part!)

For asymmetric WAN connections, it is important to ensure that all pipes and queues exists in pairs, one for each direction, and that these have the appropriate bandwidth specifications. Additionally the rules must enforce these directions. This is necessary to prevent traffic in one direction from getting into the queue(s) or pipe(s) for the other direction, which might have entirely different limitations.

References and Links

None (so far).

Contact Information ---

Any questions, comments, corrections, suggestions or additional information will be more than welcome, and should be addressed to: adam at nelleman