This topic provides a brief overview of Microsoft Internet Security and Acceleration (ISA) Server 2006 firewall policy.

For more information about ISA Server firewall policy, see the online document Best Practices Firewall Policy for ISA Server at the Microsoft TechNet Web site. (http://www.microsoft.com/)

How firewall policy works

Using ISA Server 2006, you can create a firewall policy, which includes a set of publishing rules and access rules. These rules, together with network rules, determine how clients access resources across networks.

Outgoing requests

One of the primary functions of ISA Server is to connect between source and destination networks while protecting from malicious access. To facilitate this connectivity, you use ISA Server to create an access policy that permits clients on the source network to access specific computers on the destination network. The access policy determines how clients access other networks.

When ISA Server processes an outgoing request, it checks network rules and firewall policy rules to determine if access is allowed. For Web Proxy client requests or Hypertext Transfer Protocol (HTTP), the network rule is ignored. Note that if the Web proxy is disabled, the network rule would be required.

Some rules can be configured to apply to specific clients. In this case, the clients can be specified either by IP address or by user name. ISA Server processes the requests differently, depending on which type of client requests the object and how you configure ISA Server.

First, ISA Server checks the network rules, to verify that the two networks are connected. If the network rules define a connection between the source and destination network, ISA Server processes the access policy rules.

Next, ISA Server checks the access rules, in order. If an allow rule applies to the request, ISA Server will allow the request. Specifically, ISA Server applies a rule if the request matches the following rule conditions, checking the rule elements in this order:

  1. Protocol
  2. From (source) address and port
  3. Schedule
  4. To (destination) addresses, names, URLs
  5. Users
  6. Content groups

After applying a rule, ISA Server does not match the request to any other rule and stops rule evaluation. Subsequently, ISA Server may actually deny the request, depending on the additional protocol filtering applied to the rule.

Finally, ISA Server checks the network rules again to determine how the networks are connected. ISA Server checks the Web chaining rules (if a Web Proxy client requested the object) or the firewall chaining configuration (if a SecureNAT or Firewall client requested the object) to determine how the request will be serviced.

For example, assume that you installed ISA Server on a computer with two network adapters: one connected to the Internet and the other connected to your local network. You have permissive corporate guidelines that allow all users access to all sites. In this case, your policy would consist of the following access policy rules:

  • A network rule that establishes connectivity between the source network (the local network) and the destination network (the Internet).
  • An access rule that allows all internal clients to access all sites at all times, using any protocol.

Access rules that deny traffic are processed before publishing rules. If a request matches an access rule, the request will be denied, even if a publishing rule would have allowed the request.

Incoming requests

ISA Server can make servers securely accessible to clients on another network. You use ISA Server to create a publishing policy to securely publish servers. The publishing policy (which consists of Web publishing rules, server publishing rules, secure Web publishing rules, and mail server publishing rules) and the Web chaining rules determine how published servers are accessed.

You can use one of the following ISA Server rules to publish servers:

  • **Web publishing rules—**To publish Web server content.
  • **Server publishing rules—**To publish any other content.
  • **Secure Web publishing servers—**To publish Secure Sockets Layer (SSL) content.
  • **Exchange mail publishing rules—**To publish Web client mail access on an Exchange server or server farm.

When ISA Server processes an HTTP or HTTPS request from a client, it checks publishing rules and Web chaining rules to determine whether the request is allowed, and which server will service the request.

For non-HTTP requests, ISA Server checks the network rules and then checks the publishing rules to determine if the request is allowed.

For an incoming Web request, rules are processed in the following order:

  1. Web publishing rules.
  2. Web chaining rules. For more information, see M_C_C_Distributed.

Web publishing rules and Web chaining rules

Web publishing rules are processed in order. Web chaining rules are also processed in order.

When an external client requests an object from an internal Web server, rules are processed in the following order:

  1. Web publishing rules
  2. Web chaining rules

For example, consider the following rules:

  • A Web publishing rule that redirects requests from all clients for widgets.microsoft.com to a hosted site (Web server) specified as msweb.
  • A Web chaining rule that routes requests for a destination that includes msweb by servicing them directly.

When an external (Internet) user requests an object from widgets.microsoft.com, ISA Server intercepts the request. First, it processes the Web publishing rule, determining that the request will be redirected to the msweb computer. Next, it processes the Web chaining rule, determining that the request will be serviced directly by the specified server (msweb).

The following example illustrates what happens when you create a Web publishing rule without creating an appropriate Web chaining rule:

  • A Web publishing rule that redirects requests from all clients for a destination set that includes example.microsoft.com to a hosted site specified as myinternalms.
  • A Web chaining rule that routes requests for all destinations to an upstream server.

In this case, the Web publishing rule is processed first. All requests for example.microsoft.com are redirected to myinternalms. However, the Web chaining rule specifies that the request will be routed to an upstream server (and not sent directly to the destination server). The request will always be routed to the upstream server.

How ISA Server evaluates names

When a client makes an HTTP request, it may be a name, a fully qualified domain name (FQDN), or an IP address. ISA Server handles these requests differently.

If an HTTP request uses a site name, such as http://www.fabrikam.com, ISA Server recognizes the name in the request and performs a forward name resolution to a Domain Name System (DNS) server to get the FQDN, aliases, and the IP addresses associated with that name. The result is that ISA Server has available the site name, the FQDN, the aliases, and the IP addresses to compare to the access rule requirements. Any one of those elements could be a match to the rule, depending on which element was used in the rule.

In the example of www.fabrikam.com, the following elements could match an access rule:

  • Name: www.fabrikam.com
  • FQDN: fabrikam.com
  • IP addresses:,

If an HTTP request uses an IP address, ISA Server first checks the rules to see if a rule matches that IP address. During this process, if ISA Server encounters a rule that requires a name, it performs reverse name resolution to obtain the FQDN for that IP address. ISA Server can then compare the FQDN to the access rule definitions.

If the reverse name resolution fails, only the original IP address in the request is used in comparison to the rule definitions.


When a SecureNAT client requests a site by name, ISA Server first verifies that the host header content is not masking an unrelated IP address requested by the client. If this verification succeeds, the process continues as it would for a Web Proxy client.


When rules requiring authentication are processed, ISA Server requires that the client present credentials. If the client cannot provide credentials, the request is dropped before the rule is evaluated. This implies that requests from SecureNAT clients are dropped if a matching rule requires authentication.

Enterprise-level rules can also be configured to require authentication. When an enterprise policy that includes such a rule is applied to an array, all Firewall clients must present credentials.

Single Sign-On

ISA Server provides a single sign-on functionality that allows users to move safely from one application to another without having to reauthenticate. For more information, see ISALink_SSO.

Effective array policy (ISA Server 2006 Enterprise Edition only)

Effective array policy is the firewall behavior that results from the ordered set of rules that is the combination of the array-level and enterprise-level policy rules. For more information, see ISALink_SSO.