Branch office servers are typically deployed with the end-goal of extending Central Office domain and application services across slow WAN links while simultaneously minimizing the traffic that must cross that link. Branch Office deployments tend to sift down to two basic scenarios; single-homed and multi-homed servers. In either case, the Branch Office may connect to the Internet directly or across the WAN.

Single-homed Server

Single-homed servers will either have a direct connection to the Central Office via dedicated line or an external VPN termination, but the Branch Office server does not perform traffic routing between the Branch and Central Office. ISA policies in support of domain traffic are comparatively simple in this scenario, since they need only be concerned with traffic between the ISA and the remote DC/GC and between the Branch Office hosts and ISA.

Figure 1

Multi-homed Server

Multi-homed servers may be either direct- or VPN-connected, but in either case they will act as a router between the Branch and Central Office networks. One point that bears careful consideration; when a multi-homed Branch Office server connects to the Central Office through a VPN tunnel, this creates some complicated traffic flow definition problems that must be considered carefully when defining the ISA polices. Luckily, ISA Server 2006 Enterprise Edition provides the Branch Office Connection Wizard to help you manage that process.

Figure 2

Direct Route (Leased Line)

Because of the way ISA handles traffic across the External network, we can’t use the edge templates in this scenario. Instead, what we must do is configure ISA using the 3-Leg Perimeter network template and assign the Internal network to the Branch Office and the Perimeter Network to the Central Office. Doing so has the effect of “turning ISA 90 degrees” in the network context so that the External network is left unused. Because the default network rules created by the network template wizard define a NAT relationship between the Internal and Perimeter networks, we must change the network rules so that they define a route relationship between the Internal and Perimeter networks.

Site-to-Site VPN

The best way to build this scenario is to use the Branch Office wizard found at %ProgramFiles%\Microsoft ISA Server\AppCfgWzd.exe using the template created from the Central Office Site-to-Site VPN terminating ISA. You should note that before you run the wizard at the Branch office ISA, you must perform a complete backup (export) of the existing ISA configuration. The Branch Office wizard makes changes to system policies that cannot be reverted in the management UI. Should the wizard fail after making these changes, the only way to revert those changes is by performing a complete policy restore (replace). If you haven’t made a complete backup, and the wizard fails to complete its policy changes, you will have to remove and reinstall ISA Server on the machine.

While it may be tempting to deploy CSS to each branch in an effort to minimize storage traffic between the Branch Office and the Central Office, you should avoid this unless absolutely necessary (separate Enterprise in each BO, for example). Once the Enterprise policies are in place and you don’t incur frequent changes to the Enterprise or array policies, the amount of traffic between ISA and the CSS is negligible. By default, ISA polls CSS for changes every 15 seconds. Once your policy changes have settled in, you can configure the Branch Office array such that it only polls CSS for changes much less often. Note that any time changes are made each affected ISA server is notified by the management console to refresh the settings from storage.

Should you decide to deploy CSS in the Branch Office, you *must* ensure that you adjust the system policies that control communication between all related ISA Enterprise servers are correctly configured to allow replication and CSS management access. Those system policies are defined in table 1.

Table 1

The simplest way to manage these policies is to ensure that all CSS servers in the Enterprise are included in the following Enterprise elements:

• Enterprise Remote Management Computers – this set must contain all hosts which are used to manage the Enterprise.
  
• Enterprise Configuration Storage Servers – this domain name set must be populated with the fully-qualified name of each CSS deployed in the ISA Enterprise
  
• Replicate Configuration Storage Servers – this address set must include the IP addresses of each CSS deployed in the ISA Enterprise
  

You will have to manage these lists yourself; ISA installation and the management MMC may not automatically update these sets as servers and arrays are added and deleted.

There are plenty of server administrators who still subscribe to the “kill unneeded services” methodology of server hardening. Let’s make it abundantly clear right now that the only supported method for hardening an ISA server on Windows 2003 is through the use of the Windows Security Configuration wizard in conjunction with the proper ISA Server template. If you have to deploy ISA 2004 on Windows 2000 (not a great combination, comparatively), then you must follow reference (n). Manually changing service configurations other than as described in these references is not supported at all. Properly-configured ISA Server policies provide the appropriate protection from network-based attacks, and so long as you don’t use the ISA Server as a workstation, you can minimize the application-based threats. References (n) and (o) cover the details of ISA hardening.

While it might be tempting to define each branch office as a child domain of the Central Office domain for any number of reasons, this methodology is unsupported. Since the typical Branch Office deployment provides a single domain controller, creating child domains for each Branch Office would create service startup failures for the Branch Office server applications; especially ISA services. Thus, if the server were to be rebooted unexpectedly, it might be rendered unavailable until someone accessed it locally from the console. If the server is unattended when this occurs, it could be a weekend (or longer, depending on how remote this office may be) before this server could be brought back online. Instead, you should create an OU in the Central Office domain for each branch office and manage your Active Directory policies that way.

Domain controllers use a well-defined set of protocols to perform various tasks and functions. These include well-known items such as ICMP (ping), LDAP and DNS as well as less well-known protocols such as NetBIOS Session and NetBIOS Datagram. To help illustrate this process, ref (c) provides an excellent description of the most common domain controller activities; machine startup and user logon, effectively illustrating the use of several protocols involved in these two processes. Ref (d) provides a complete listing of all protocols used by various Windows servers and services. Between them, they form the basis of the core knowledge required to understand how to construct secure, reliable ISA policies for domain controller communications.

Unfortunately for the firewall administrator, domain communications and some MMC mechanisms rely on protocols such as RPC and DCOM that challenge the goal of creating secure firewall policies. This, coupled with the NAT relationship created by most firewalls, prompted the publication of refs (e), (f), (g), (h) and (k).

Our primary reference for this part of the discussion is ref (d). If you eliminate the application-specific protocols, such as SMTP, POP3 and others, it’s clear that the domain traffic profile consists of a pretty well-defined set of protocols. It’s when we include ISA and network service protocols and the various LOB applications that this set grows considerably.

Table 2

Notes:

1. Dyn = 1025-65535 on WS03 and earlier; 49152-65536 on Vista and later
   
2. Nego = connection port is negotiated between client/server pair
   
3. Only required if the server is configured for LDAP-SSL
   
4. RFC specifies that NTP clients should use source UDP:123, but Windows time uses dynamic ports
   
5. Secondary connection transport / protocols are negotiated in the control channel according to client application Winsock usage
   
6. Firewall Web Management is used by OEM to provide non-MMC management of ISA Server
   
7. Remote management of ISA Server using the ISA Management MMC involves the use of RPC mechanisms to monitor ISA service status
   
8. ISA Server installation creates an SMB connection to the CSS to validate the credentials chosen by the user
   

In order to preserve the domain controller functionality for the server where ISA operates, the domain services need to have access to the network during ISA services startup. Since it’s the responsibility of the ISA Server System Policies to handle traffic when the firewall service is unavailable (as during startup), we need to define the proper traffic profile using the system policies. By default, the following default policy groups and rules related to domain controller traffic exist with their settings as indicated in table 3:

Table 3

There are quite a few more system policies, and some of them even duplicate some of these rules because of their association with specific functionality, but these are what we’ll use to allow server communication with remote domain controllers. One disadvantage with the System policy management UI is that it restricts the changes you can make to these rules. In the case of the policies defined above, you can only change the destination (“To”) portion of the rule; you cannot change the source (“From”). As such, we’ll have to define array-level policies that mimic these system policies so as to allow domain-related traffic to flow in the proper directions. Depending on the complexity of the branch office scenario where you deploy the ISA/DC server, you may have to adjust the rule elements used in the following examples. For instance, if you have another Branch Office connected to the Central Office through an upstream Branch Office, you’ll have to consider that in your policy rule “From” configuration. There are four basic traffic flow contexts that we have to accommodate for each deployment scenario (single- or multi-homed):

• CSS traffic between the Branch Office ISA/DC/CSS and the Central Office CSS
  
• Domain traffic between the ISA/DC and the Central Office DC/GC
  
• Domain traffic between the Branch Office hosts and the ISA/DC
  
• Domain traffic between the Branch Office hosts and the Central Office DC/GC
  

1. Represent the smallest possible protocol set. While this seems like an obvious statement, what it really means is that you as the firewall administrator charged with controlling traffic between two separate locations must have a complete knowledge of the traffic generated by your organization’s applications and services as well as that created by the network structure. This requires that you work very closely with the network and application administrators and developers so that the network traffic picture is clear. Once you have this defined, you can start limit your policies to a clearly defined set of protocols.
   
2. Restrict the policies to a clearly-defined set of hosts. This is accomplished by limiting the source and destination criteria of each rule. For instance, your firewall policies are much more secure if they allow DC-oriented traffic only from known hosts in a specific network, such as domain controllers, than it is to allow it from the entire network. While it’s true that such heavily-restrictive firewall policies increase the management overhead, the results are frequently worth the trouble.
   
3. Limit the policies to users and/or groups whenever possible. This may require that you configure all browsers to use the proxy, or that you deploy the Firewall Client. You will probably note that in all of the domain traffic policy examples, there is no mention of limitation to users or groups. This is because much of the traffic generated by domain-related client services is handled in kernel mode. ISA cannot authenticate traffic that is sourced from the client in kernel mode and so those rules must be anonymous.
   

As functionality and security best practices goals are frequently at odds, only the business and security managers in the organization can decide how best to resolve the conflicts. The point of this discussion is to help the ISA administrators clearly define and control domain-related traffic between their central and branch offices. The use of “allow all” policies to “make life easier” is just as likely to make life harder when some custom-ported malware makes its way into your environment.

One thing to note as you gather all the IP ranges, subnets and host IPs to limit your policies to only known entities; the two ISA servers which comprise the two endpoints of a site-to-site communicate to each other and hosts on the remote side of the VPN connection using the IP addresses they assign each other as part of the VPN connection. For instance, let’s examine the following diagram:

Figure 2

When you create a Site-to-Site VPN, the two endpoints will generally create two separate connections; one from each ISA server to the other. This behavior results in each ISA owning two IP addresses related to the tunnel.

The Central Office ISA includes IP addresses within the 10.10.255.0 - 10.10.255.255 range for the Internal network, while the Branch Office ISA includes the address range 10.10.254.0 - 10.10.254.255 range for its Internal network. The Site-to-Site VPN connection between them uses an address range of 10.10.0.0 - 10.10.0.7. Since there are only six functional addresses within that range (we don’t need or even use them all), we’ve assigned 10.10.0.1 and 10.10.0.2 to the Central Office ISA and 10.10.0.3 and 10.10.0.4 to the Branch Office ISA. The routing tables in each ISA server are automatically updated during the VPN connection process to include the VPN tunnel IP range and the RRAS service in each ISA server manages the routing to the opposite networks behind each ISA.

When the Branch Office ISA needs to communicate with a host in the Central Office Internal network, the traffic will be seen by the Central Office host as coming from 10.10.0.3 (or 10.10.0.4); the VPN tunnel address for the Branch Office ISA server. Likewise, when the two ISA Servers communicate with each other, they will use their VPN tunnel IP address to do so. Since the network relationship between Internal and “Remote” for each ISA Server must be “Route” (NAT breaks domain traffic, remember?), the traffic crossing the VPN tunnel from the ISA Internal network will use the original host’s source IP.

If you opted to deploy a CSS at the local branch as a replica of the Central Office CSS, then you’ll also need to configure the proper system policies. The simplest way to do this is to update the policy elements that determine the source and destination of the relevant traffic as described in Configuration Storage Servers.

System Policies

Enterprise or Array Policies

System Policies

Enterprise or Array Policies

To enable domain traffic between the Branch Office hosts and the ISA/DC server, we need to mimic the system policies outlined above, but with a few changes to allow traffic to the ISA/DC server, rather than from it. The simplest policy would appear as:

Table 4

Because ISA does not support traffic routing in a single-network template and the Branch Office hosts have access to the Central office network without routing through the ISA/DC, ISA policies can have no effect on this domain traffic.

If you opted to deploy a CSS at the local branch as a replica of the Central Office CSS, then you’ll also need to enable the proper system policies. The simplest way to do this is to change the policy elements that determine the source and destination of the relevant traffic as described in Configuration Storage Servers. Note that if you have configured ISA using the Branch Office Configuration wizard, you no longer have a local CSS instance.

System Policies for Site-to-Site VPN

If the ISA Server was joined to the domain as part of the Branch Office Configuration wizard action, the system policies were updated to allow this traffic. Otherwise, you should make the changes as indicated in bold:

Table 5

System Policies for Direct Route

Because the Central Office resides on the Perimeter network, we must change the system policies that apply to domain communications to appear as shown below (changes in bold):

Table 6

Enterprise or Array Policies

System Policies

Enterprise or Array Policies

To enable domain traffic between the Branch Office hosts and the ISA/DC server, we need to mimic the system policies outlined above, but with a few changes to allow traffic to the ISA/DC server, rather than from it. The simplest policy would appear as:

Table 7

System Policies

Enterprise or Array Policies

The following policies are required to meet this need:

Table 8