Specifies which low-level protocol is used for the protocol definition: TCP, UDP, ICMP, or IP-level.

ISA Server uses protocol direction to specify whether traffic is considered outbound or inbound. For TCP, this includes Inbound and Outbound. For UDP this includes Send, Receive, Send Receive, or Receive Send. For ICMP and IP-level, this includes Send and Send Receive.

For access rules, protocol direction is usually defined as outbound. This allows traffic from the network entities specified as the rule sources (From) to the network entities specified as the rule destinations (To). Generally, this means that a client behind ISA Server is allowed to send traffic to other network objects or networks, such as the External network (Internet).

For server publishing rules, protocol definition must be defined as inbound. This allows traffic from the network entities specified as the network sources to the published service on the server. For server publishing rules, predefined protocols are always identified with the suffix Server. For example, DNS Server protocol allows requests for Domain Name System (DNS) services to reach the published DNS server. When you define protocols for server publishing, you are not required to add the suffix. However, you must define the protocol as inbound.

For TCP and UDP, this is a range of ports between 1 and 65,535 that is used for the initial connection.

More than one protocol can be associated with the same port.

If you create a rule denying access to a specific protocol, be sure to include all protocols that use the same port in the exception list. Alternatively, you can create a rule denying any one of the protocols that use the port, and place the deny rule before the access rule in the rules order.

For example, if you create a protocol to be used in a rule that denies access to a virus, do not create an access rule that allows access to everything except the new protocol. Instead, create a rule that denies access to the new protocol. Place this rule before any other access rules that allow protocols on the same ports as the new protocol.

For IP-level protocols, this is a number between 0 and 254.

• For ICMP, this is the ICMP code and type.
  

• This is the range of ports, protocol types, and direction used for additional connections or packets that follow the initial connection. You can configure one or more secondary connections.
  
• Secondary connections is an optional property. You cannot define secondary connections for IP-level primary protocols.
  

When you install ISA Server, two default RPC protocol definitions are provided for incoming requests:

• RPC Server (all interfaces). If this protocol definition is allowed in a server publishing rule, ISA Server will map any inbound RPC requests to the published RPC server. If the universally unique identifier (UUID) is registered on the RPC server, access to the procedure is given. If the UUID is not registered on the RPC server, the request is dropped.
  
• Exchange RPC server. A list of UUID interfaces used for Microsoft Exchange Server is defined as an RPC protocol definition. You can use this protocol definition in server publishing rules to deny or allow access to specific Exchange functions.
  

You can create additional RPC protocol definitions. Using the New RPC Protocol Wizard, you can either select UUID interfaces from a list of interfaces available on the RPC server, or you can define the interfaces manually. If you do not specify any interfaces for the incoming RPC protocol definition, server publishing rules that allow this protocol definition do not allow any traffic.

When you install ISA Server, an outbound RPC protocol is defined for outgoing requests. All UUID interfaces are used for this protocol definition.

You can create access rules that allow use of this outbound RPC protocol definition. This can allow internal clients to use the RPC protocol to access external resources. For example, you can allow clients on the Internal network access to an external Exchange server. Similarly, you can create outgoing RPC protocol definitions, and use these in access rules, to allow internal clients access to external resources.

Outbound RPC protocols can be configured on a per-rule basis, to enforce strict RPC compliance. By default, strict compliance is enforced for RPC protocols. By enforcing strict compliance, RPC-type protocols, such as DCOM, will not be allowed through ISA Server.

Enterprise Networks (Enterprise Edition Only)

ISA Server processes rules that apply to URL sets only for Web traffic (for client requests for HTTP or FTP over HTTP). When a client uses any other protocol, ISA Server does not process rules that apply only to a URL set.

Note the following behavior in matching requests with rules containing URL sets:

• Only the host name and path are considered in a request.
  
• The protocol part of the URL is stripped from requests and ignored.
  
• You can also specify a path. Wildcard characters can be used in the path, but only at the end. For example, www.microsoft.com/* is acceptable. However, www.microsoft.com/*/sales is not acceptable.
  
• Although the URL can include a specific port number, ISA Server ignores that port number when processing the rule. Any port number specified is stripped from requests and ignored.
  
• If a request includes a question mark (?), the question mark and everything following it are stripped from the request before matching.
  
• When matching, the host and path names are not case-sensitive. For example, this means that folderA and foldera would be considered the same path.
  
• For HTTP or FTP over HTTP, when the URL is specified in a request without a path, it will match any path. For example, http://a.com or a.com is equivalent to http://a.com/*.
  
• For HTTPS traffic, URL sets are only processed if the URL does not have a path specified, for example, http://a.com or a.com. If the URL has a path specified, for example a slash mark (/), it is ignored for HTTPS traffic.
  
• When ISA Server checks the URL sets configured for a rule, text after a question mark (?) is ignored. URLs with a ?, which are included in a URL set, are ignored.
  

Possible protocols are HTTP, HTTPS, and FTP. However, when ISA Server processes a rule that applies to a URL set, the protocol specified is ignored—only the host name and path are considered.

ISA Server determines whether requests should be allowed or denied in accordance with access policy. The ISA Server rules engine attempts to match access rules, and then routing rules, with requests. Rules that include domain name sets and URL sets require name resolution. If there are no rule criteria that prevent rule matching, and the rule may match the request if name resolution is performed, the rule will be subject to name resolution. If the rule contains a URL set, but a schedule limitation on the rule prevents matching, the rule is not subject to name resolution. The following types of requests may be marked for name resolution:

• A Web request specified by name encounters a rule that has an address range specified as the destination criteria (forward lookup).
  
• A Web request specified by IP address encounters a rule that has a URL set as the destination criteria (reverse lookup).
  

The Microsoft Firewall service includes its own Domain Name System (DNS) cache. If the requested IP address or host name resides in this cache, the request is processed without issuing a DNS request. Otherwise, a DNS request is issued. Name resolution provides a host entry, and the rules engine then compares the host entry against the destination criteria of the rule. The rules engine does a string compare against URL sets and domain name set entries.

Note that rules requiring name resolution are evaluated and enforced in accordance with DNS resolution information. If DNS information is not configured correctly or securely, rules may not be applied as required.

Some URL set mapping examples are as follows:

• For a URL set that includes the URL ftp://a.com:25/apath, requests for http://a.com and for http://a.com:55 will be matched, because protocol and port are stripped.
  
• For a URL set that includes the URL http://a.com, requests for http://a.com/abc will be matched, as will requests for http://a.com/abc/def. For example, http://a.com is the equivalent of http://a.com/*. The exception is for HTTPS requests, which will not be processed because a path is specified.
  
• For a URL set that includes the URL http://a.com/a, requests for http://a.com/a will be matched. But requests for http://a.com/a/b will not be matched. In such an entry, requests are not matched to the tree following "a."
  
• For a URL set that includes the URL http://www.a.com/apath?next=news, the question mark and everything following will be stripped from requests. If this URL set was specified in a deny rule, and a request arrives for http://www.a.com/apath?next=news, the request is stripped to http://www.a.com/apath. It would be allowed because it does not match the URL set specified in the deny rule. To block such a request, you should specify http://www.a.com/apath in the URL set.
  
• For a URL set that includes the URL a.com, HTTPS requests will be matched, because no path is specified.
  
• For a URL set that includes the URL b.com/, HTTPS requests will not be matched, because a path (/) is specified.
  

When you apply a rule to a domain name set, ISA Server checks whether the request matches the specified domain name set. ISA Server checks the exact name that you specified, including port numbers. For example, consider a Web publishing rule that allows access to a domain name set that includes fabrikam.put:1111. Requests to fabrikam.put will be denied. Requests to fabrikam.put will be allowed only if the domain name set is changed to include fabrikam.put. For this reason, do not specify a port number in a domain name set.

When creating a domain name set, note the following:

• When you specify a domain name, specify the computer name using the fully qualified domain name (FQDN). For example, computer_name.microsoft.com, and not \\computer_name. You cannot specify a domain name set as an IP address. When specifying the domain name, you can use an asterisk (*) to specify a set of computers. For example, to specify all computers in the Microsoft.com domain, type the domain name as *.microsoft.com. Note that the asterisk can appear only at the start of the domain name, and can be specified only once in the name.
  
• When you create a domain with a wildcard character, such as *.microsoft.com, this only includes host computers at the domain, for example www.microsoft.com, ftp.microsoft.com. Note that if the domain name points to a host, *.microsoft.com will have no effect on the URL http://Microsoft.com.
  
• We recommend that you enter the domain name as it is returned by the Domain Name System (DNS). If you specify a dot at the end of a domain name, a request for the domain name (without a dot) may not be matched as required.
  
• When matching rules, the domain name is not case-sensitive.
  

ISA Server determines whether requests should be allowed or denied in accordance with access policy. The ISA Server rules engine attempts to match access rules, and then routing rules, with requests. Rules that include domain name sets and URL sets require name resolution. If there is no rule criteria that prevents rule matching, and the rule may match the request if name resolution is performed, the rule will be subject to name resolution. If the rule contains a URL set, but a schedule limitation on the rule prevents matching, the rule is not subject to name resolution.

The following types of requests may be marked for name resolution:

• A Web request specified by name encounters a rule that has an address range specified as the destination criteria (forward lookup).
  
• A Web request specified by IP address encounters a rule that has a URL set as the destination criteria (reverse lookup).
  

The Microsoft Firewall service includes its own DNS cache. If the requested IP address or host name resides in this cache, the request is processed without issuing a DNS request. Otherwise, a DNS request is issued. Name resolution provides a host entry, and the rules engine then compares the host entry against the destination criteria of the rule. The rules engine does a string compare against URL sets and domain name set entries.

Note that rules requiring name resolution are evaluated and enforced in accordance with DNS resolution information. If DNS information is not configured correctly or securely, rules may not be applied as required.

The Web listener network, or networks, that you select depend on which network clients will use to connect to the published Web server. For example, if the Web site you are publishing allows client requests from the Internet (External network), you should select the External network for the Web listener. By selecting the External network, you are selecting the IP addresses on the ISA Server computer that are associated with the external network adapter. If you do not limit the IP addresses, all IP addresses associated with the selected network adapter will be included in the listener configuration.

Web listeners are used by a Web publishing rule. The rule specifies source network objects in addition to specifying a Web listener. The network objects specified for the Web publishing rule must also be specified for the Web listener.

Each Web listener can be used for one or more Web sites. However, ISA Server limits one certificate per IP address. If all the Web sites use the same certificate, you can publish using the same Web listener. However, if different certificates are required, you must do one of the following:

• Install a wildcard certificate.
  
• Add an IP address to the listening network adapter on the ISA Server computer (or array in ISA Server Enterprise Edition) for each SSL-enabled Web site.
  

For example, you want to publish three SSL Web sites: www.treyresearch.net, www.Finance.treyresearch.net, and www.Marketing.treyresearch.net. All three sites are registered in a public DNS, and resolve to the same IP address. You must install a wildcard certificate for *.treyresearch.net to publish these sites. Alternatively, you could add more IP addresses.

In ISA Server 2004, wildcard certificates are supported only on the ISA Server computer. In HTTPS-to-HTTPS bridging, you cannot use wildcard certificates to authenticate the back-end Web server to ISA Server. In ISA Server 2006, wildcard certificates are supported on both the ISA Server computer and the back-end Web server.

For more information about wildcard certificates, see "Publishing Multiple Web Sites using a Wildcard Certificate in ISA Server 2006" at the Microsoft TechNet Web site. Most of the procedures in this document are applicable for ISA Server 2006.

By limiting the number of connections allowed simultaneously to the ISA Server computer, you can prevent attacks that overwhelm the system's resources. This is particularly useful when publishing servers. You can limit the number of computers that connect, while allowing for specific clients to continue connecting, even when the limit is surpassed.

By default, ISA Server listens on port 80 for HTTP requests. If, however, connecting clients are expected to use a different port, you should change the port number accordingly. You can also enable the Web listener to listen for SSL requests on the default port 443. If you choose SSL, an appropriate certificate must first be installed on the ISA Server computer. You must select a server certificate to be used by the Web listener so that the ISA Server computer can authenticate itself to the client.

In many scenarios, for load balancing to be effective, affinity must be maintained between the client and the Web server that receives and responds to the client's request. Otherwise, a series of requests from the client and responses from the Web farm will be handled by different Web servers, ignoring the context of the requests. For example, Outlook Web Access is an application that requires client affinity, because the Outlook Web Access server maintains a context for the connected client.

The need for affinity is also demonstrated in a Web shopping scenario, where a client sets up a shopping cart on a Web server. If affinity is not maintained, at some point in the client's session, the client's requests may be directed to another Web server that is unaware of the shopping cart.

When you apply a rule to a server farm, you can also configure if the load balancing mechanism should be cookie based or source-IP based.

We recommend that you use session affinity when possible, because it provides more reliable client affinity when a Web server is restarted. This is sometimes referred to as client stickiness. It also works better in a situation where you are draining a Web server. Session affinity should be used for load balancing Outlook Web Access or Microsoft Windows SharePoint® Services access, both of which use Microsoft Internet Explorer®, and therefore support HTTP cookies.

IP address-based affinity has an advantage over session affinity in that it supports clients that are not fully compliant with HTTP 1.1 (clients that do not support HTTP cookies), such as some mobile devices. IP address-based affinity must also be used in a scenario where you are load balancing RPC over HTTP Outlook access. Outlook does not work with HTTP cookies, and therefore cannot use session affinity.

Note that if you are publishing a server farm with ISA Server 2006 located behind another firewall, you must either use session affinity, or use IP address affinity and verify that the front-end firewall is configured to pass the original client's IP address to ISA Server.

When you create a server farm, ISA Server creates a connectivity verifier for each Web server. Note that if your Web servers use a port other than port 80, specify that port on the server farm properties Connectivity Verification tab. You can view connectivity verifier status for the server farm in the Monitoring node, on the Connectivity Verifiers tab.

ISA Server provides a Drain option allowing you to specify that a server in the farm should temporarily stop accepting new connections. When you are ready for the server to begin accepting connections again, the Resume option is available.

Note that Drain and Resume are only active after you click the Apply button on the Apply Changes bar. When you drain a server, it stops accepting new connections. However, existing connections are not dropped.