Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard

[patris1]

http://www.isaserver.org/tutorials/Creating-VPN-ISA-2006-Firewall-Branch-Office-Connection-Wizard-Part1.html

PART-1


How to configure a site to site VPN using the branch office connectivity wizard.

Branch Office Domain Controller Scenario

One of the improvements included with the Enterprise Edition of the 2006 ISA Firewall is the branch office connectivity wizard. In ISA 2000, we had the site to site VPN wizard that made is very easy to create a site to site VPN. However, in ISA 2004, our beloved site to site VPN wizard disappeared, and people had no end of difficulties getting site to site VPN working between two ISA Firewalls. The ISA Firewall dev team heard our pleas, and now we have an excellent site to site VPN wizard, which has been rechristened as the Branch Office Connectivity Wizard.

The Branch Office Connectivity Wizard uses information contained in the Remote Site configuration you create at the main office and uses that information to help make it easier for you to create the site to site VPN. When you’re done with the wizard, a file is created that you can take to the branch office ISA Firewall to create the site to site VPN. In addition to creating the site to site VPN connection, the wizard gives you the option to make the branch office ISA Firewall a domain member, which is an ISA Firewall best practice, since the overall security posture of a domain member ISA Firewall is superior to a standalone ISA Firewall. For proof of this assertion, please read the definitive white paper on ISA Firewall domain membership.
In this article series on using the ISA Firewall Branch Office Connectivity Wizard to create a site to site VPN, I’ll first go through the process of creating the site to site VPN connection using the Wizard, and then after the site to site VPN is complete, we’ll create Access Rules that allow for a branch office domain controller and domain member clients to be located at the branch office and use least privilege to do this.
The figure below shows a high level view of the lab network used in this article series.

Figure 1
There are five machines used in this scenario:

• Dedicated CSS (css2006.msfirewall.org) A dedicated CSS will be used to house the CSS for the ISA Enterprise Edition firewall arrays. There will be two ISA Firewall arrays: one array for the ISA Firewall array at the main office, and an ISA Firewall array at the branch office. We can’t put the main and branch office ISA Firewalls in the same array, because the intra-array communications addresses for all array members must be on the same network ID, and that’s not possible when array members are located at branch offices. However, we can apply enterprise policy to all arrays in the same ISA Firewall enterprise
• Domain Controller (dc.msfirewall.org) All machines in this scenario belong to the same domain, which is msfirewall.org.
• Main office ISA Firewall (isa2006se.msfirewall.org) This machine is the main office ISA Firewall and will belong to an array named Main. This machine is a domain member, and has an internal and external interface.
• Branch office ISA Firewall (isa2006branch.msfirewall.org) This machine is the branch office ISA Firewall and will be made a member of the domain using the branch office connectivity wizard. Windows Server 2003 is installed on this machine and the machine is initially a standalone server. ISA 2006 will be installed on this machine while the machine is a standalone server. After ISA 2006 Enterprise Edition is installed on this machine, we will run the Branch Office Connectivity Wizard on this machine, which will create the site to site VPN and join the machine to the domain. The wizard will also connect the branch office ISA Firewall to the branch office array configured on the main office CSS.
• Branch office Domain Controller This is a branch office domain controller that branch office users will use to authenticate. We will create custom Access Rules that will allow the DC to communicate with the DC at the main office.

We will also make changes to the DNS configuration of the branch office ISA Firewall so that it uses the branch office DC after the configuration is complete.
Procedures include:

• Configure the main office DNS server to reject dynamic updates and add static DNS entries for array names and the branch office ISA Firewall
• Install the CSS on the dedicated CSS machine
• Install the Firewall services on the main office ISA Firewall
• Install a local CSS and Firewall Services on the branch office ISA Firewall
• Create the answer file at the main office ISA Firewall that will be used by the branch office connectivity wizard
• Run the Branch Office Connectivity Wizard on the branch office ISA Firewall
• Create Access Rules that allow intradomain communications between the main and branch office domain controllers
• Install the DC at the branch office
• Make DNS changes at the branch office so that the ISA Firewall uses the branch office DC

Notes on Site to Site VPNs

One of the busiest sections of the ISAserver.org Web boards are the VPN sections, and it’s often site to site VPN connection issues that fill up the VPN board posts. I think the reason for this is that a lot of people don’t understand how site to site VPN connections work and what some of the basic requirements for these are.

The VPN Gateway is a VPN Router

When the ISA Firewall is configured as a site to site VPN gateway, the ISA Firewall becomes a router to the network IDs located behind the remote VPN gateway. For example, suppose that the main office is located on network ID 10.1.0.0/16 and the branch office IP addresses are located on network ID 10.2.0.0/16. When a host at the main office needs to connect to the remote network ID, 10.2.0.0/16, it must do so through the VPN gateway at the main office.
In order for this to work, the clients on the main office network must be configured with a gateway address that knows the route to network ID 10.2.0.0/16. The ISA Firewall clearly knows the route, so clients that are configured to use the ISA Firewall as their default gateway will be able to reach the remote network through the ISA Firewall’s VPN gateway. For client systems that do not use the ISA Firewall as their default gateway, those hosts must be configured to use a LAN router that is configured with a routing table entry to forward connections to network ID 10.2.0.0/16 to the ISA Firewall’s LAN IP address.
I see a lot of questions regarding how to “fix” the problems seen when the local and remote sites are addressed using the same network ID. They want to know if there is a way to “fix” this problem. The answer is that there really is no way to fix this problem from a routing point of view, since client systems connecting to local network IDs will never forward connections to a gateway address. Why would clients forward connections to a local network ID to a gateway when that’s not required and violates all tenets of TCP/IP routing principles?
Remember Name Resolution

Another common problem with site to site VPNs is name resolution. Clients at the branch office need to be able to resolve names for computers at the main office, and often at the branch office as well. In order to do this, there needs to be a DNS server infrastructure in place that can resolve all of these names. In addition, you need to think about whether users at the branch office should be able to resolve Internet host names directly, or depend on the ISA Firewall either at the main or branch offices to resolve Internet host names on their behalf.
There are two primary scenarios regarding name resolution at the branch office: one whether there is a domain controller at the branch office and the other where there is no domain controller at the branch office. If the company keeps DCs at the branch office, the hosts at the branch office can use their local domain controller for logging on and name resolution, as that machine can be configured as an Active Directory integrated DNS server. If there is no DC at the branch office, then the clients at the branch offices can be configured to use the main office DNS servers for name resolution for main and branch office servers.
Internet host name resolution is a separate issue. Some organizations will be happy to allow clients to resolve Internet host names themselves (which is required for SecureNET clients), while other organizations may want to have tight control over Internet host name resolution and only allow the ISA Firewall to resolve names on behalf of the clients.
There are many ways to approach Internet host name resolution and it’s impossible for me to give you a hard and fast rule about which is best. However, what I most often do is configure the ISA Firewalls and the hosts on the corporate networks to use Active Directory integrated DNS servers to resolve host names, and then configure the Active Directory integrated DNS to use a forwarder controlled by the company to resolve Internet host names.
An important name resolution issue in a branch office environment is related to WPAD entries. As you know, both the Web proxy and Firewall clients use WPAD entries to automatically discover the local address of the ISA Firewall to use for Web proxy and Firewall client connections to the ISA Firewall. This can be problematic when you use a single DNS infrastructure for the main and branch offices, since you can’t use the single WPAD entry for all locations, assuming that you want hosts to connect to local ISA Firewalls, which is most often the case. On the other hand, if you want all hosts to connect to the Internet through a single main office Firewall array, then it is possible to use a single WPAD entry.
You can solve the problem by creating multiple WPAD entries, one for the main office and one for each of the branch offices and then enabling netmask ordering on the DNS servers. When netmask ordering is enabled, the DNS servers will resolve the WPAD queries to match the network ID from which the request is received. That means that when a host at the main office sends a WPAD query to DNS, the address returned will be one closest to the network ID of the host at the main office and when a WPAD query is received by a host at a branch office, the address returned will be the one closest to the network ID where the branch office host is located.
For more information on how to do this, check out Stefaan Pouseele’s article.
One final DNS issue that you need to consider is the effect of DDNS registrations for VPN gateways. When DDNS is enabled on a DNS server, the ISA Firewall’s RAS interface will register itself in DNS and create connectivity issues for Web proxy and Firewall clients, as they will try to connect to the RAS interface and not the actual LAN address of the ISA Firewall. For this reason, in the scenarios discussed in this article series, we’ll disable DDNS on our DNS servers when creating the VPN gateways and then we’ll investigate whether it’s possible to disable DDNS registration in the demand-dial interface using the RRAS console.
VPN Protocols

The ISA Firewall supports three VPN protocols for site to site VPNs: IPSec tunnel mode, L2TP/IPSec and PPTP.
IPSec tunnel mode support was introduced with ISA 2004 so that the ISA Firewall could be used as a site to site VPN gateway with third party VPN gateways. This is the only scenario where you should use IPSec tunnel mode, as IPSec tunnel mode is considered to be less secure and lower performance compared to L2TP/IPSec. In addition, routing support for IPSec tunnel mode is abysmal, laborious and limited.
L2TP/IPSec is the preferred site to site VPN protocol when both sides of the site to site VPN are using ISA Firewalls, or when the third party VPN gateway supports L2TP/IPSec. While L2TP/IPSec supports pre-shared keys, in a secure production environment you would used certificate authentication for both the machine accounts and the user accounts used to authenticate the VPN tunnel. While this is a very secure configuration, most companies I’ve worked with prefer to use non-EAP authentication for the demand-dial interface user accounts and use certificate authentication for the machine accounts.
PPTP is the easiest protocol to support for site to site VPN connections. No certificates are required and most ISA Firewall admins find that PPTP “just works”. The drawback is that PPTP is a bit less secure than L2TP/IPSec because the credentials hash is sent over a non-encrypted channel. Therefore, the level of security the PPTP connection can provide is highly dependent password complexity. In addition, PPTP doesn’t provide the non-repudiation features and protection from replay that L2TP/IPSec provides.
When using IPSec tunnel mode to connect to third party VPN gateways, there’s no easy way out. The first thing you should try is the information on using the ISA Firewall with third party VPN gateways at the Microsoft site.
If that guidance does not address your deployment scenario, then you’re going to have to fall back on your understanding of IPSec and make sure that all IPSec parameters are correct on both sides. Even if you get the IPSec parameters correct on both sides, you can run into problems with non-RFC compliant VPN gateways. For example, I’ve heard several reports of Sonicwall firewalls not working with the ISA Firewall VPN gateway because they are not RFC compliant and do not allow the source port for the IKE to be anything than UDP 500. Since the ISA Firewall is RFC compliant, it may use an alternate port and therefore not connect to the Sonicwall device. In the case of the Sonicwall, there may be a software update to make the device RFC compliant.
Another common problem is that the site to site VPN user accounts are not correctly configured to match the demand-dial interface names. When this happens, there are times when it may appear that the site to site VPN is connected, but no traffic passes through the VPN gateways from one network to another, or it might seem like connections are allowed from one network, but not from the other network. The reason for this is that a site to site VPN connection was not established. You can confirm this by opening the RRAS console and checking the Remote Access Clients node in the left pane of the RRAS console. If you see a remote access client connection for the remote VPN gateway, then you know that the a remote access client VPN connection was made, not a site to site VPN connection. Remote access client connections will not allow routing through the VPN gateways.
As for my recommendation, I always recommend that ISA Firewall admins use L2TP/IPSec with machine certificate authentication. However, in most cases, during the initial deployment, I will set up the site to site VPN using a pre-shared key, so as to build confidence in the solution and remove some of the complexities inherent in a PKI. After the site to site VPN solution has completed a short shake down period, I’ll move the customer to machine certificate authentication and away from pre-shared keys.

Summary

This article is the first part of a series on how to configure a site to site VPN using the branch office connectivity wizard. In this scenario there will be ISA Firewalls at the main and branch offices as well as domain controllers at the main and branch offices. We’ll see how to use the branch office connectivity wizard included with ISA 2006 Enterprise Edition to create the connection and then we’ll customize access rules, DNS and other configuration parameters to fully support the site to site VPN connection from the branch office. See you next week! –Tom.

---

موضوعات مشابه:

• وی پی ان site to site توسط آیزا 2006 و مطالب مرتبط به آن
• Creating a Site to Site VPN using ISA 2006 Firewalls at the Main and Branch Office

---

[patris1]

http://www.isaserver.org/tutorials/Creating-VPN-ISA-2006-Firewall-Branch-Office-Connection-Wizard-Part2.html

PART-2


The DNS issues required to make the solution work, and installing the CSS and creating the main and branch office ISA Firewall arrays.

In the first part of this series on how to use the branch office connectivity wizard to create a site to site VPN between a main and branch office, we went over the example network infrastructure and discussed some key concepts in creating site to site VPNs.
In this, part 2 of the series, we’ll explore the DNS issues required to make the solution work, and then install the CSS and create the main and branch office ISA Firewall arrays.

Configure the DNS Server to Reject Dynamic Updates and Enter Host (A) Records for the ISA Firewall Computer and Array Names

Before we begin with installing the CSS at the main office and the ISA Firewall arrays, the first step is to configure the DNS server on the corporate network to deny dynamic updates. We need to do this so that when the branch office ISA Firewall connects to the main office ISA Firewall that it’s virtual IP address isn’t registered in DNS instead of the actual internal IP address of the branch office ISA Firewall. This will also prevent the main office ISA Firewall from registering its virtual IP address in DNS as well.
This is a very common issue for connectivity problems related to site to site VPN connections. For example, suppose you use Web proxy and Firewall clients on the main office network and those clients are configured to use the name of the ISA Firewall to connect to the ISA Firewall’s Firewall and Web proxy services. Everything works fine until the site to site connects. After the site to site connection establishes, the virtual IP address of the main office registers itself in the DDNS. Now when the Web proxy and Firewall clients try to connect to the main office ISA Firewall, they try to connect to the main office ISA Firewall’s virtual IP address (RAS interface address) and the connections from the Web proxy and Firewall clients fail.
Another scenario where registration of the virtual (RAS) interface IP address creates problems is when the branch office ISA Firewall tries to connect to the main office CSS. When the site to site connection completes, the branch office ISA Firewall registers it’s virtual (RAS) interface address in the CSS. The CSS tries to communicate with the branch office array Firewall using this address and the connection fails.
We can prevent these problems by disabling DDNS on the DNS server. You might ask “do we need to do this permanently, or is there a way that we can configure the demand-dial interfaces to not register in the DDNS?” The answer to this question is “maybe”. I don’t want to give away the answer this early in the article series, or else you might not continue reading.
We need to create Host (A) records in our Active Directory integrated DNS for the following names:

• isa2006se.msfirewall.org (10.0.0.1)
• isa2006branch.msfirewall.org (10.0.1.1)
• main.msfirewall.org (10.0.0.1)
• branch.msfirewall.org (10.0.1.1)

We don’t need to enter records for the CSS machine or the domain controller because those machines have already been installed and registered in DNS using DDNS. We don’t need to worry about those machines because their IP addressing information isn’t going to change based on the connection state of the site to site VPN connection.
Before you create the Host (A) records, you need to create a reverse lookup zone for the branch office network ID. In our current example, the branch office network ID is 10.0.1.0/24. Perform the following steps to create the reverse lookup zone:

1. On the domain controller, click Start and then point to Administrative Tools. Click DNS.
2. In the DNS management console, expand the server name and then click the Reverse Lookup Zones node.
3. Right click the Reverse Lookup Zone node and click New Zone.
4. On the Welcome to the New Zone Wizard page, click Next.
5. On the Zone Type page, select the Primary Zone option and click Next.

Figure 1

1. On the Active Directory Zone Replication Scope page, select the To all DNS servers in the Active Directory domain msfirewall.org option. We select this option because there is only a single domain in our organization. If you had multiple domains, you might want to replicate this reverse lookup zone to all DNS servers in the forest. Click Next.

Figure 2

1. On the Reverse Lookup Zone Name page, select the Network ID option and enter the network ID for the branch office in the text box. In this example the branch office network ID is 10.0.1.0/24, so we’ll enter 10.0.1 and click Next.

Figure 3

1. On the Dynamic Update page, select the Allow only secure dynamic updates (recommend for Active Directory) option. We don’t want to take away the option of using dynamic updates for this zone, since we want the branch office servers to be able to register in the DDNS. We only want to avoid the demand-dial interfaces from registering in DNS, and we’ll check later to see if this is possible. Click Next.

Figure 4

1. Click Finish on the Completing the New Zone Wizard page.
2. You’ll see the new zone in the left pane of the DNS management console.

Figure 5
Now we’re ready to create the Host (A) records. Use the following procedure to add the Host (A) records to DNS:

1. On the domain controller, click Start, point to Administrative Tools and click DNS.
2. In the DNS management console, expand the server name and then expand the Forward Lookup Zones node. Click on the msfirewall.org node.
3. Right click on the msfirewall.org node and click the New Host (A) command.
4. In the New Host dialog box, enter the host name of the server in the Name (uses parent domain name if blank) text box. In this example we’ll enter the name of the branch office ISA Firewall, which is isa2006branch. The FQDN will then appear in the Fully qualified domain name (FQDN) text box. Enter the internal IP address of the branch office ISA Firewall in the IP address text box. In this example the IP address of the branch office ISA Firewall is 10.0.1.1, so we’ll enter that into the text box. Click Add Host.

Figure 6

1. The New Host dialog box remains open to allow you to enter more Host (A) entries. Enter the names and IP addressing information for the entries noted in the list above for the local ISA Firewall name, as well as the array names.
2. After you enter all the records, click Cancel in the New Host dialog box.
3. Your list should look something like that in the figure below.

Figure 7

1. We now need to get these entries loaded into the DNS database. We can do that by restarting the DNS server. In the DNS console, right click the server name, point to All Tasks, and click Restart.

Figure 8
To finish off the DNS configuration, we need to disable dynamic updates (at least temporarily). In the left pane of the DNS console, click on the msfirewall.org entry in the Forward Lookup Zones node. Right click the msfirewall.org node and click Properties.
In the Properties dialog box, click the General tab. On the General tab, select the None option from the Dynamic updates drop down list. Click OK. There’s no need to restart the DNS service for this option to take effect. Minimize the DNS console.

Figure 9
Install the CSS on the Dedicated CSS Computer

Now that the critical step of setting up DNS is completed, we can move to the next step, which is installing the CSS on the dedicated CSS computer. While it’s possible to install the CSS on a DC, or even on the ISA Firewall array itself, the best and most secure configuration is to place the CSS on a dedicated device that is off DCs and array members.
In an ideal setup, the CSS is placed on a dedicated network security segment where no other machines are located, and no traffic is allowed to the CSS machine from any other segment, using the ISA Firewall to protect the CSS from all other machines. However, in order to simplify things a bit in this article series which already has its own complexities, I haven’t set things up that way. In the future I might focus on how to set up this configuration. However, you can use the principles discussed in the many DMZ articles on this site, especially those on how to secure FE Exchange Servers.
Perform the following steps to install the CSS on the dedicated CSS computer:

1. Put the ISA 2006 CD into the computer. If the autorun menu doesn’t start, double click on the ISAAutorun.exe file to bring up the autorun menu.
2. On the autorun menu, click the Install ISA Server 2006 link.
3. Click Next on the Welcome to the Installation Wizard for Microsoft ISA Server 2006 page.
4. Select the I accept the terms in the license agreement option on the License Agreement page and click Next.
5. Enter your customer information on the Customer Information page and click Next.
6. On the Setup Scenarios page, select the Install Configuration Storage Server option and click Next.

Figure 10

1. Click Next on the Component Selection page.

Figure 11

1. On the Enterprise Installation Options page, select the Create a new ISA Server enterprise option. This option allows you to create a new enterprise. In contrast, the Create a replica of the enterprise configuration option allows you to create a copy of an existing ISA Firewall enterprise, which can be used as a backup CSS in case the primary CSS goes down. In this example we need to create a new enterprise which will contain all of our arrays. Click Next.

Figure 12

1. On the New Enterprise Warning page you see information about the value of using a single enterprise to manage all of your arrays. Click Next.

Figure 13

1. On the Create New Enterprise page, enter a name for the new ISA Firewall enterprise in the Enterprise name text box. In this example, we’ll use the name Enterprise. You can enter a description for this ISA Firewall enterprise in the Description text box. Click Next.

Figure 14

1. In the Enterprise Deployment Environment dialog box, you tell the installation wizard whether or not the ISA Firewalls, as the CSS, are part of the same domain, or if they’re in a workgroup. ISA Firewall best practices for security and ease of configuration dictate that all should be part of the same domain, so we’ll go with those best practices. There are some circumstances where the “network guys” may have hijacked network security and thus don’t understand the ISA Firewall and thus will try to force you to deploy in a less secure and less flexible workgroup configuration. If you’re in that unfortunate position, you’ll need to deploy in a workgroup, which means deploying a PKI and making sure all machines have the appropriate certificate.
   
   Since we’re deploying a secure configuration, the ISA Firewall members and the CSS are part of the same domain, so select the I am deploying in a single domain or in domains with trust relationships option. Click Next.

Figure 15

1. On the Ready to Install the Program page, click Next.

Figure 16

1. The progress bar will inform you the state of the installation and what activities the installer is performing at any point in time.

Figure 17

1. On the Installation Wizard Completed page, put a checkmark in the Invoke ISA Server Management when the wizard closes. Click Finish.

Figure 18

Create the Arrays and Configure the Enterprise Management Station

Now we’re ready to create the arrays for the main and branch offices. An array is a collection of ISA Firewalls that act as a single logical firewall, in that they all have the same firewall policy and configuration. An ISA Firewall array can consist of 1 to 32 servers. At least one interface on each ISA Firewall array member must be on the same network ID as all other ISA Firewall array members in the same ISA Firewall array, as this interface is used for intra-array communications. In practice, this means that you cannot extend arrays across WAN links or site to site VPNs, as all interfaces in the remote offices are going to be on a network ID which is different from that at the main office.
In the example used in this series, we will have two arrays: a main office array named Main and a branch office array named Branch. We could create multiple main office arrays and multiple branch office arrays, and each array could contain up to 32 members. In practice, branch offices will typically contain a single array member, while main offices and large branch offices will contain arrays members of 2-32 servers.
One of the great advantages of using multiple array members is that the CARP and NLB load balancing mechanisms allow you to increase effective throughput by the sum of the array members per array times the link speed available to each array member.
For example, for stateful packet inspection, a typically configured ISA Firewall can pass traffic at approximately 1.5Gbps. If you have a main office array containing 5 array members, the effective throughput through the array is 7.5Gbps. Try pricing out a “hardware” firewall that has 7.5Gbps throughput and compare it to the cost of the five member array on stock computer hardware.
You’ll be impressed by the cost savings, as well as the ability to get parts and replacement parts at commodity prices, and not at the insane markups charged by the “hardware” firewall vendors. Take the money you save and buy yourself a Corvette, instead of buying the Corvette for the hardware firewall sales guy.
Let’s get back to the ISA Firewall console. After you click Finish on the last page of the installation wizard, the ISA Firewall console opens as well as the security Web page. Perform the following steps to add the CSS to the Enterprise Remote Management stations in enterprise policy:

1. Read the Protect the ISA Server Computer Web page and then close it.
2. In the ISA Firewall console, expand the Enterprise node and then expand the Enterprise Policies node. Click on the Default Policy node.

Figure 19

1. Click the Toolbox tab in the Task Pane. Click the Network Objects heading. Click the Computer Sets folder and then double click on the Enterprise Remote Management entry.

Figure 20

1. In the Enterprise Remote Management Computers Properties dialog box, click the Add button and click the Computer entry.

Figure 21

1. In the New Computer Rule Element dialog box, enter a name for the CSS machine, which also acts as an enterprise remote management station. We’ll name this computer CSS and enter that name in the Name text box. In the Computer IP Address text box, enter the IP address of the CSS machine. In our example, the IP address is 10.0.0.3. Enter a description for this machine in the Description (optional) text box. Click OK in the New Computer Rule Element dialog box.

Figure 22

1. Click OK in the Enterprise Remote Management Computers Properties dialog box.
2. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

Now we need to create the arrays. There will be two arrays in this scenario: a main office array and a branch office array. Both arrays will be managed in the same ISA Firewall enterprise and will be manageable using the centralized enterprise policies. Perform the following steps to create the Main array:

1. In the left pane of the ISA Firewall console, right click on the Arrays node. Click the New Array command.

Figure 23

1. In the Welcome to the New Array Wizard dialog box, enter a name for the array in the Array name text box. In this example we’ll name the array Main. Click Next.

Figure 24

1. In the Array DNS Name text box, enter a FQDN that identifies the array name. This is useful for when you’re using NLB or client side CARP for load balancing. In this example, we’ll use the name main.msfirewall.org which resolves to the IP address of the internal interface of the main office ISA Firewall. If we had NLB enabled, this name would resolve to an internal VIP, and if we were using client side CARP, we would have multiple Host (A) records for this name and use DNS round robin for distributing the initial connections to receive the array table information. Click Next.

Figure 25

1. On the Assign Enterprise Policy page, select the default option, Default Policy. Later we’ll investigate how to use enterprise policies that apply to all arrays managed by the same ISA Firewall enterprise. Click Next.

Figure 26

1. On the Array Policy Rule Types page, you can exert some centralized control over the types of rules that can be configured by array administrators. Leave the default settings “Deny” Access Rules, “Allow” Access Rules and Publishing rules (Deny and Allow) enabled and click Next.

Figure 27

1. Click Finish on the Completing the New Array Wizard page.

Figure 28

1. A Creating a new array progress bar appears as the array is created.

Figure 29

1. Click OK after The new array was successfully created appears.

Figure 30

1. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

Now let’s create the branch office array:

1. Right click on the Arrays node and click New Array.

Figure 31

1. Enter Branch in the Array name text box. Click Next.

Figure 32

1. Enter branch.msfirewall.org in the Array’s DNS name text box. This will resolve to the internal IP address on the branch office ISA Firewall. Click Next.

Figure 33

1. Accept the Default Policy entry on the Assign Enterprise Policy page and click Next.

Figure 34

1. Accept the default settings on the Array Policy Rule Types page and click Next.

Figure 35

1. Click Finish on the Completing the New Array Wizard page.

Figure 36

1. The status bar indicates the progress in creating the new array.

Figure 37

1. Click OK when you see The new array was successfully created.

Figure 38

1. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

One last thing to do before we finish. Click the link at the top of the middle pane regarding the customer experience improvement program. This brings up the Customer Feedback dialog box. I highly recommend that you participate in the program, as it helps the ISA Firewall product group understand how you use the ISA Firewall and how to more quickly respond to problems or issues you might be having with your ISA Firewall. No information that could compromise your security posture is sent to Microsoft and the end result will be a more secure and stable ISA Firewall product for you and everyone else who uses the ISA Firewall.

Figure 39

Summary

In this article on how to create a site to site VPN using the branch office connectivity wizard, we configured the DNS server with Host (A) records to support the solution. After configuring DNS, we installed the CSS on a dedicated CSS machine and then configured the main and branch office arrays on the CSS. Next week we’ll continue by using the branch office connectivity wizard to create the answer file and then use that answer file to create the site to site VPN connection and join the branch office ISA Firewall to the domain and main office CSS. See you then! – Tom.

[patris1]

http://www.isaserver.org/tutorials/Creating-VPN-ISA-2006-Firewall-Branch-Office-Connection-Wizard-Part3.html

PART-3


Installing the ISA Firewall services on the main office and branch office ISA Firewalls.

Branch Office Domain Controller Scenario – Installing ISA Firewall Services on the Main and Branch Office ISA Firewalls

In part 1 in this series on how to use the branch office connectivity wizard to create a site to site VPN connection between ISA 2006 Enterprise Edition Firewalls at main and branch offices, we discussed the core network infrastructure used in this article series and then went into a detailed discussion on core requirements for site to site VPNs and how to troubleshoot more common site to site VPN problems.

In part 2 of the series we configured the DNS server with the appropriate DNS entries required to make the solution work and disabled DDNS so that the ISA Firewall VPN gateway would not register its VPN PPP interface in the DDNS. We then installed the CSS on a dedicated CSS machine and created two ISA Firewall Arrays on the CSS: one ISA Firewall Array for the main office and one ISA Firewall Array for the branch office.
In this, part 3 of the series, we’ll install the ISA Firewall services on the main office and branch office ISA Firewalls.
Install the ISA Firewall Services on the Main Office ISA Firewall

We now have the CSS and Firewall Arrays defined in the CSS. We can now install the ISA Firewall services on the main office ISA Firewall and point the main office ISA Firewall to the main office CSS. Remember, all configuration information for members of ISA Firewall arrays is stored on and obtained from the CSS. You can’t directly configure the ISA Firewall array members themselves, all configuration must be done on the CSS and the CSS provides this configuration information to the ISA Firewall array members.
The main office firewall will be configured during the installation process to use the dedicated CSS computer as it’s CSS provider and will also be configured to join the Main array at that time. System Policy will be automatically configured to allow the ISA Firewall to communicate with both the CSS and the domain controller. We’ll take a look at this system policy after installing the ISA Firewall services on the main office ISA Firewall.
Perform the following steps to install the ISA Firewall services on the main office ISA Firewall:

1. Put the ISA 2006 CD into the CD drive and wait for the autorun menu to appear. If the autorun menu doesn’t appear, double click the ISAAutorun.exe file on the ISA 2006 Enterprise Edition CD.
2. On the ISA autorun menu, click the Install ISA Server 2006 link.
3. On the Welcome to the Installation Wizard for Microsoft ISA Server 2006 page, click Next.
4. On the License Agreement page, select the I accept the terms in the license agreement option and click Next.
5. Enter your customer information and product serial number on the Customer Information page and click Next.
6. On the Setup Scenarios page, select the Install ISA Server Services option and click Next.

Figure 1

1. Accept the default settings on the Component Selection page and click Next.
2. On the Locate Configuration Server page, enter the FQDN of the CSS machine. In this example, the FQDN of the CSS machine is css2006.msfirewall.org, so we’ll enter that into the Configuration Storage server (type the FQDN) text box. In the Connection Credentials frame, select the Connect using the credentials of the logged on user if you’re logged on as a domain administrator. If you’re not logged on as a domain administrator, then select the Connect using this account option and enter the appropriate credentials. In this example we’re logged on as a domain admin, so we’ll select the Connect using the credentials of the logged on user option and click Next.

Figure 2

1. On the Array Membership page, select the Join an existing array option and click Next.

Figure 3

1. On the Join Existing Array page, click the Browse button. This brings up the Arrays to Join dialog box which provides a list of available arrays. Click the Main array and click OK.

Figure 4

1. Click Next on the Join Existing Array page.

Figure 5

1. On the Configuration Storage Server Authentication Options page you select how the ISA Firewall machine will authenticate to the CSS. You have two options: Windows authentication and Authentication over SSL encrypted channel. The first option is preferred, as it requires both the ISA Firewall and the CSS to be part of the same domain, which is the most secure configuration. However, if you are hamstrung by “network guys” or “the security team” who don’t understand the ISA Firewall and somehow think it’s Windows 95 with Zone Alarm installed, you may be stuck with either the ISA or both the ISA Firewall not being domain members. In that case, you would have to use machine certificate authentication and SSL encrypted channel.
   
   If you are stuck using authentication over SSL, you will need to install the CA certificate of the machine that issued the machine certificate for the CSS on the ISA Firewall device.
   
   In our current example, both the ISA Firewall and the CSS are domain members, so we don’t need to worry about certificates at this point. Select Windows authentication and click Next.

Figure 6

1. On the Internal Network page you define the IP addresses that form the definition of the default Internal Network. The default Internal Network is typically the Network that contains the domain controllers and other key infrastructure servers, such as DNS, WINS, and certificate services. Click the Add button.

Figure 7

1. On the Addresses page, click the Add Adapter button.

Figure 8

1. In the Select Network Adapters dialog box, put a checkmark in the checkbox next to the NIC representing the internal interface of the ISA Firewall. In this example, I’ve renamed the NICs so that they’re easy to identify. Remember that you need to do more than just click on the name of the NIC, you need to get the checkmark in the checkbox. Click OK.

Figure 9

1. Click OK in the Select Network Adapters dialog box, then click OK in the Addresses dialog box, and then click Next on the Internal Network page.
   
   Note that the range of IP addresses that appear here are those which define the default Internal Network. If you find that there are addresses missing from this list, it would indicate that you haven’t configured the routing table on the ISA Firewall for routes for other network IDs located behind the ISA Firewall’s internal interface. If you haven’t yet configured the routing table to include all internal network IDs, quit the installation program and do that now, then restart the installation.

Figure 10

1. The Services Warning page informs you that during installation the setup program will stop the SNMP Service, the FTP Publishing Service, the NNTP Service, the IIS Admin Service and the World Wide Web Publishing Service. In a correctly deployed ISA Firewall setup, none of these services except for the SNMP service should be installed on the ISA Firewall. If you want the installation routine to install the SNMP MIB objects, then you’ll need to install the SNMP service on the ISA Firewall before you begin the installation. Click Next.

Figure 11

1. Click Install.

Figure 12

1. A progress bar provides information about the state of the installation and what procedures the setup routine is carrying out.

Figure 13

1. Click Finish on the Installation Wizard Completed page.

Figure 14

1. Go the to CSS computer and open the ISA Firewall console. Expand the Arrays node and then expand the Main array node. Expand the Configuration node and then click the Servers node. You should see the name of the main office ISA Firewall there and a green checkmark on the icon, which indicates that communications between the CSS and the main office ISA Firewall are working correctly.

Figure 15

Install a Local CSS and Firewall Services on the Branch Office ISA Firewall

One of the major problems ISA 2004 Firewall admins had with branch office deployments of the ISA Firewall was the complexity of the deployment. Admins needed some way to provision the branch office ISA Firewall device at the main office and ship a box that is ready to deploy at the branch office. The complexity of the configuration was increased because many ISA Firewall admins realized that domain membership is a key security and flexibility requirement, and making a branch office ISA Firewall that terminates a site to site VPN a domain member was very difficult and required that experienced ISA Firewall admins be at the branch office during installation.
The 2006 ISA Firewall solves this problem with the branch office connectivity wizard. The branch office connectivity wizard allows you to provision the branch office ISA Firewall at the main office and ship it to the branch office. A power user at the branch office can be provided instructions on how to plug in the power and network cables and how to run the branch office connectivity wizard.
The power user doesn’t need to make any decisions because the provisioned ISA Firewall will contain an answer file that provides the branch office connectivity wizard all the answers. The branch office power user only needs to start the application and click through the screens. The wizard will establish the VPN connection, join the ISA Firewall to the domain, restart, and connect to the correct CSS and array.
Before shipping the box to the branch office, you should install a local CSS and ISA Firewall service on the branch office firewall. This requires that you assign the IP addresses to the internal and external interface that will be used at the branch office, and all NICs need to be connected to a hub or switch during this phase of the installation. Before installing the ISA Firewall software, you should assign the machine a valid local address and default gateway so that you can install all the Windows Updates.
After installing the updates, you then change the IP addressing information on the ISA Firewall’s NICs so that they match the numbers that will be used at the branch office.
Perform the following steps on the branch office ISA Firewall machine:

1. Put the ISA 2006 Firewall CD into the branch office machine and wait for the autorun menu. If the autorun menu doesn’t appear, then double click on the ISAAutorun.exe file on the CD. Click the Install ISA Server 2006 link.
2. Click Next on the Welcome to the Installation Wizard for Microsoft ISA Server 2006 page.
3. Select the I accept the terms in the license agreement option on the License Agreement page. Click Next.
4. Enter your customer information and product serial number on the Customer Information page and click Next.
5. On the Setup Scenarios page, select the Install both ISA Server services and Configuration Storage server option and click Next.

Figure 16

1. Accept the default settings on the Component Selection page and click Next.

Figure 17

1. On the Enterprise Installation Options page, select the Create a new ISA Server enterprise option. We need to do this because this machine needs to be configured as a single server local CSS array member before we run the branch office connectivity wizard to join the machine to the domain and then configure it to use the CSS at the main office. Click Next.

Figure 18

1. On the New Enterprise Warning page, there is information regarding creating new ISA Firewall enterprises. This information does not apply to our current configuration so click Next.

Figure 19

1. On the Internal Network page, click the Add button. In the Addresses dialog box, click the Add Adapter button.

Figure 20

1. In the Select Network Adapters dialog box, put a checkmark in the checkbox next to the internal interface of the branch office ISA Firewall. The IP addresses that will define the default Internet Network at the branch office will appear in the Network adapter details frame in this dialog box. If this information is incorrect, that indicates the routing table on the branch office ISA Firewall wasn’t correctly configured. If you have multiple network IDs located behind the internal interface of the branch office ISA Firewall, you must configure the routing table for those networks before installing the ISA Firewall. If you have not done this yet, quit the installation wizard and make the correct routing table entries and then restart the ISA Firewall installation wizard.
   
   In this example I’ve named the NICs to make them easier to identify. Put a checkmark in the checkbox next to the internal interface and click OK.

Figure 21

1. Click OK in the Addresses dialog box.

Figure 22

1. The addresses that define the default Internal Network now appear on the Internal Network page. Click Next.

Figure 23

1. On the Firewall Client Connections page, accept the default setting which is to not allow non-encrypted Firewall client connections to the ISA Firewall and click Next.

Figure 24

1. On the Service Warning page, there is information that lets you know that the SNMP Service, FTP Publishing Service, NNTP Service, IIS Admin Service and World Wide Web Publishing Service will be stopped during the installation. No well designed ISA Firewall should have any of these services installed on them, except for the SNMP service. If you want to use the ISA Firewall MIB objects, then make sure the SNMP service is installed on the ISA Firewall device before installing the ISA Firewall software. Click Next.

Figure 25

1. Click Install to complete the installation.

Figure 26

1. A progress bar displays the current state of the installation and what installation tasks the setup program is performing.

Figure 27

1. Click Finish on the Installation Wizard Completed page.

Figure 28

1. Close the Internet Explorer window showing the Protect the ISA Server Computer page and restart the branch office ISA Firewall computer.

At this point the branch office ISA Firewall is almost ready to ship to the branch office. However, before we do that, we’ll have to create the answer file on the main office CSS computer and copy that answer file to the root of the C: drive on the branch office ISA Firewall. After we complete that step, we’ll be able to ship the box to the branch office.

Summary

In this, part 3 of our article series on using the branch office connectivity wizard to create a site to site connection between main and branch office ISA 2006 Firewall VPN gateways, we went through the procedures involved with installing the main office ISA Firewall services on the main office ISA Firewall and joining that ISA Firewall to the main office ISA Firewall array. We then installed a local CSS and ISA Firewall services on the branch office ISA Firewall. This allowed us to provision the branch office ISA Firewall at the main office before shipping it to the branch office. In the next article in this series, we’ll create the site to site VPN connection at the main office by creating the Remote Network, and then we’ll create the answer file that the branch office Power User will use to create the site to site VPN connection to the main office. See you then! –Tom.

[patris1]

http://www.isaserver.org/tutorials/Creating-VPN-ISA-2006-Firewall-Branch-Office-Connection-Wizard-Part4.html

PART-4

Configuring the main office ISA firewall with the Remote Site Network that is used to create the site to site VPN connection from the main office to the branch office.

In the first three parts of this series on using the branch office connectivity wizard to connect the branch office ISA firewall to the main office ISA firewall, we discussed the example network infrastructure, went over important concepts in creating site to site VPNs, configured the supporting network services, and then installed the CSS, main office ISA Firewall and branch office ISA Firewall. At the end of part 3 in this series, the branch office ISA Firewall was ready to accept the answer file that will be used by the branch office connectivity wizard.

In this, part 4 in the series we’ll continue by configuring the main office ISA firewall with the Remote Site Network that is used to create the site to site VPN connection from the main office to the branch office. After we create the Remote Site Network, we can use the answer file wizard to create the answer file that the branch office connectivity wizard will use to create the site to site VPN connection from the branch office to the main office. The branch office connectivity wizard will also allow you to automatically join the branch office ISA Firewall to the domain, which provides us with the highest security and flexibility possible.
Create the Remote Site Network to Connect to the Branch Office over Site to Site VPN

Now we need to create the remote site network that initiates the site to site VPN connection from the main office to the branch office. After the site to site VPN connection configuration is completed, we can create an answer file and copy it to the root of the C: drive of the branch office ISA Firewall. The branch office connectivity wizard will automatically find the answer file to complete the configuration of the branch office ISA Firewall’s site to site VPN connection to the main office.
Perform the following steps to create the site to site VPN connection at the main office ISA Firewall that connects to the branch office ISA Firewall:

1. At the CSS machine, expand the Arrays node and then expand the Main array node. Click the Virtual Private networks (VPN) node. Click the Remote Sites tab in the middle pane of the ISA Firewall console and then click the Tasks tab in the Task Pane. On the Task Pane, click the Create VPN Site to Site Connection link.

Figure 1

1. On the Welcome to the Create [sic] VPN Site to Site Connection Wizard page, enter a name for the remote site in the Site to site network name text box. This is the name of the demand dial interface on this ISA Firewall that will accept the incoming connection from the branch office ISA Firewall. You will need to create a user account on this machine that has dial-in permissions that has this same name. The wizard will warn us about this later and we’ll create the user account after we complete the wizard. Click Next.

Figure 2

1. On the VPN Protocol page, select the Layer Two Tunneling Protocol (L2TP) over IPSec option. This is the preferred option when you’re connecting two ISA Firewalls in a site to site VPN connection, which is the case in our scenario. You can use the branch office connectivity wizard only when there are ISA Firewalls on both sides of the site to site VPN link. The branch office connectivity wizard only works when you use either L2TP/IPSec or IPSec tunnel mode. Avoid the use of IPSec tunnel mode, as it is less secure and has much lower performance compared to L2TP/IPSec, because of its lack of header compression. If you choose PPTP as your VPN protocol, the option to create the answer file based on the remote site network configuration will not be available. Click Next.

Figure 3

1. A warning dialog box will appear the informs you that you need to create a user account with the same name as the demand dial interface on this machine, which is the same as the name you gave to the remote site network at the beginning of the wizard. We’ll create this account when we finish creating the remote site network site to site VPN connection. Click OK.

Figure 4

1. On the Local Network VPN Settings page, select the method the ISA Firewall will use to assign IP addresses to remote access VPN clients and VPN gateways. In our current example, the main office has an on-subnet DHCP server, so we’ll select the Dynamic Host Configuration Protocol (DHCP). Note that DHCP isn’t supported for multiple member ISA Firewall arrays. Click Next.

Figure 5

1. Accept the default setting on the connection owner page. Since this is a single member ISA Firewall array, there is only a single machine that can be the connection owner. If we had multiple members in this ISA Firewall array, and had NLB enabled, then NLB would automatically assign the connection owner for the site to site VPN connection. Click Next.

Figure 6

1. On the Remote Site Gateway page, enter the FQDN or IP address of the branch office ISA Firewall. In this example, the IP address of the branch office ISA Firewall will be 192.168.1.73 so we enter that value into the text box (note that I’m using private IP addresses in the lab – in a production environment the ISA Firewall would of course be on the network edge and have a public IP address). Enter the IP address in the Remote site VPN server text box and click Next.

Figure 7

1. On the Remote Authentication page, you enter credentials the main office ISA Firewall can use to connect to the branch office ISA Firewall for the site to site VPN connection. Put a checkmark in the Allow the local site to initiate connections to the remote site, using this user account checkbox, then enter the User name, Domain, Password and Confirm Password information into the text boxes.
   
   I prefer to use a local account on the machine, rather than a domain account. In fact, we can’t use a domain account in this scenario, because the branch office ISA Firewall will not be a domain member until after the initial site to site VPN connection is established. In our scenario, we will, on the branch office ISA Firewall, create a user account with the name main on the branch office ISA Firewall which is named ISA2006BRANCH. This explains the information in the figure below. Click Next.

Figure 8

1. On the L2TP/IPSec Outgoing Authentication page, you select whether you want to use certificate authentication or a pre-shared key. In a production environment, I typically start with a pre-shared key and then after everything is working the way we expect, move to machine certificate authentication.
   
   Select the Pre-shared key authentication option and then enter a key. In this example I’m using 123 for simplicity sake. In a production environment, use a complex key of more than 14 characters. Click Next.

Figure 9

1. On the Incoming L2TP/IPSec Authentication page, select the authentication method you want the branch office ISA Firewall to use when creating the IPSec connection with the main office ISA Firewall. In this example, we’ll use the same method we use to dial out from the main office, using a pre-shared key and the key value of 123. Click Next.

Figure 10

1. On the Network Addresses page, you enter the IP address ranges used on the remote site network. Click the Add Rangebutton. In the IP Address Range Properties dialog box, enter the range of addresses used at the branch office. In this example, the branch office machines are located on network ID 10.0.1.0/24. Enter 10.0.1.0 in the Start address text box and 10.0.1.255 in the End address text box. Click OK.

Figure 11

1. The branch office address range now appears in on the Network addresses page. Click Next.

Figure 12

1. On the Remote NLB page, remove the checkmark from the The remote site is enabled for Network Load Balancing checkbox, since we’re not using NLB at the branch office. Click Next.

Figure 13

1. On the Site to Site Network Rule page, you are given the opportunity to create a Route Network Rule between the main and branch offices over the site to site VPN. Accept the default selection Create a network specifying a route relationship option and the default name for the rule and then click Next.

Figure 14

1. On the Site to Site Network Access Rule page, you can create an Access Rule that controls traffic moving over the site to site VPN at the main office ISA Firewall. In this example, select the Create an allow access rule option. Leave the default name for the Access Rule in the Access Rule name text box. From the Apply the rule to these protocols drop down list, select the All outbound traffic option. We’ll lock things down later, but at the beginning we want to make sure the site to site VPN successfully establishes and that the branch office ISA Firewall is able to join the domain. After the site to site VPN connection is stabilized, we’ll lock things down so that access to the appropriate intradomain communications and server access is allowed. Click Next.

Figure 15

1. On the Completing the New VPN Site to Site Network Wizard page, click Finish.

Figure 16

1. The Remaining VPN Site to Site Tasks dialog box appears informing you that you need to create the user account on the main office ISA Firewall that the branch office ISA Firewall can use to authenticate to the main office ISA Firewall for the site to site VPN connection. Click OK.

Figure 17

1. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.
2. Click on the Branch entry in the site list of the site to site VPN connections and click on the Tasks tab. Notice in the Related Tasks list that there is a new option: Create Answer File for Remote VPN Site. This option becomes available after creating the site to site VPN remote network and is only available in ISA 2006 Enterprise Edition. If you’re using ISA 2006 Standard Edition, then you’ll have to do all this work yourself, without benefit of answer files.

Figure 18
Now we need to carry out the configuration task the site to site VPN wizard asked us to carry out: we need to create the user account that the branch office ISA Firewall will use to authenticate to the main office ISA Firewall. Perform the following steps on the main office ISA Firewall computer (NOT the CSS) to create the user account and finish up the configuration:

1. Right click on the My Computer object on the desktop and click the Manage command.

Figure 19

1. In the Computer Management console, expand the System Tools node and then expand the Local Users and Groups node. Right click in an empty portion of the right pane and click the New User command.

Figure 20

1. In the New User dialog box, enter Branch in the User name text box. This is a critical setting, as the name of this user must be the same as the name assigned to the demand dial interface on the main office ISA Firewall used to connect to the branch office ISA Firewall. Enter a password and confirm the password. Remove the checkmark from the User must change password at next logon and put checkmarks in the User cannot change password and Password next expires checkboxes. Click the Create button.

Figure 21

1. Click Close in the New User dialog box.
2. Double click on the Branch user to bring up the Branch Properties dialog box.

Figure 22

1. Close the Computer Management console.
2. Restart the ISA Firewall computer.

Summary

In this article, part 4 of our series on creating a site to site VPN using the branch office connectivity wizard, we went through the procedures required to create the Remote Site Network that enables the site to site VPN connection from the main office to the branch office. We also created the user account at the main office that the branch office ISA Firewall will use to establish the site to site connection from the branch office to the main office. In the next part of this series, we’ll use the site to site VPN answer file wizard to create the answer file that we’ll transfer to the branch office ISA Firewall. See you then!

[patris1]

http://www.isaserver.org/tutorials/Creating-VPN-ISA-2006-Firewall-Branch-Office-Connection-Wizard-Part5.html

PART-5

Creating the answer file at the main office that will be used by the branch office connectivity wizard on the branch office ISA Firewall.

Branch Office Domain Controller Scenario

In the first four parts of this series on using the branch office connectivity wizard to connect the branch office ISA firewall to the main office ISA firewall, we discussed the example network infrastructure, went over important concepts in creating site to site VPNs, configured the supporting network services, and then installed the CSS, main office ISA Firewall and branch office ISA Firewall. At the end of part 3 in this series, the branch office ISA Firewall was ready to accept the answer file that will be used by the branch office connectivity wizard. Part 4 discussed creating the site to site VPN network to connect the main office to the branch office.

In this, part 5 in the series we’ll finish up the basic configuration of the site to site VPN by creating the answer file at the main office that will be used by the branch office connectivity wizard on the branch office ISA Firewall. This article will finish up with us running the branch office connectivity wizard on the branch office ISA Firewall to create the site to site VPN and join the branch office ISA Firewall to the domain.
Create the Answer File for the Site to Site VPN Connection at the Main Office ISA Firewall

Now we’re ready to create the answer file that the branch office connectivity wizard on the branch office ISA Firewall will use to create the site to site VPN connection and join the branch office ISA Firewall to the domain. This answer file uses information in the site to site VPN connection created on the main office ISA Firewall, so the first step is to create the site to site VPN connection at the main office ISA Firewall that connects it to the branch office ISA Firewall.
We’ll place the answer file in the root of the C: drive of the branch office ISA Firewall. If you don’t want to put the answer file in the root of the C: drive, you can put the file on a removable storage device, such as a USB key. The branch office connectivity wizard will automatically search the root of the C: drive and removable drives for the answer file.
When running the answer file wizard, keep in mind that the site to site connection created by this answer file is from the perspective of the branch office ISA Firewall. Therefore, when the wizard refers to the local site, it’s actually referring to the branch office, and when the wizard refers to the remote site, its actually referring to the main office.
Perform the following steps on the CSS machine to create the answer file:

1. Click the Create Answer File for Remote VPN Site link in the Task Pane. Click Next on the Welcome to the Create Answer File Wizard.

Figure 1

1. On the Answer File Details page, enter the full path to the answer file in the Type the full path to the answer file text box. You must name the answer file IsaUsrConfig.inf if you want the branch office connectivity wizard to automatically find the file. In this example, we’ll put the answer file in the root of the C: drive on the CSS machine. Click Next.

Figure 2

1. There are no decisions to make on the Connection Type page, as the VPN protocol used for the site to site VPN connection is read from the existing configuration. Click Next.

Figure 3

1. On the Array Server Deployment page, select the This is the first server deployed in the array option. If there was already another server in the array, we would have selected the Another server is already deployed in the array and then provide the internal IP address of that server to allow intra-array communications between the array members. Click Next.

Figure 4

1. On the Local Site to Site Authentication page, the network name Main is automatically added for you. This is the name of the user account on the branch office ISA Firewall that the main office ISA Firewall will use to authenticate to the branch office ISA Firewall. The wizard will automatically create this account for you on the branch office ISA Firewall and configure the account with dial-in permissions. Click Next.

Figure 5

1. On the Remote Site VPN IP Addresses page, the addresses defined in the default Internal Network at the main office are automatically entered for you. Enter the IP address of the main office ISA Firewall in the Remote VPN server (IP address or name) text box. Remember, when using the answer file wizard, the remote site is actually the main office. Click Next.

Figure 6

1. On the Local Network VPN Settings page, select the Static IP address pool option. We need to select this option because we don’t have a DHCP server located at the branch office. If we later install a DHCP server at the branch office, we can change the IP addressing configuration for VPN so that it uses DHCP. Click the Add Range button. In the IP Address Range Properties dialog box, enter a range of IP addresses that the branch office ISA Firewall can use to assign to VPN clients and remote VPN gateways. In this example we’ll enter 10.0.1.252 for the Start address and 10.0.1.254 in the End address. Click OK, and then click Next on the Local Network VPN Settings page.

Figure 7

1. On the Remote Authentication page, enter the credentials that the branch office will use to authenticate to the main office ISA Firewall. We already created the account on the main office ISA Firewall named Branch and we’ll enter that account name on this page. This is a local account, so we’ll use the computer name of the main office ISA Firewall computer in the Domain text box. Enter the information and click Next.

Figure 8

1. On the IPSec Authentication page you decide whether you want to use certificate or pre-shared authentication for the IPSec connection. In our current example we’re starting with pre-shared keys and then later after everything works, we’ll move to machine certificate authentication. Select the Use pre-shared key option and enter the pre-shared key 123, in this example. Click Next.

Figure 9

1. On the Join Remote Domain page, select the Join a domain option. This allows the branch office connectivity wizard to join the branch office ISA Firewall to the domain, which is the more secure and more flexible option. In the Domain name (FQDN) text box, enter the FQDN of the main office domain. In this example, the main office domain is msfirewall.org, so we’ll enter that information into the text box. Click Next.

Figure 10

1. A Join Domain dialog box appears. Enter a username and password of a user who has the right to join a machine to the domain (such as domain admin) and click OK.

Figure 11

1. On the Locate Configuration Storage Server page, enter the name of the CSS machine in the Configuration Storage Server (type the FQDN) text box. This must be a FQDN, not an IP address or machine (NetBIOS) name. Select the Connect using this account option in the Connection Credentials frame. It’s not an absolute necessity to choose this option, but I found that sometimes the installation of the branch office ISA Firewall will freeze up after the reboot if you log on as a domain user, so it’s more efficient to log on as the local administrator and then have the branch office connectivity wizard use these credentials for the remainder of the configuration. Click Next.

Figure 12

1. On the Securely Published Configuration Storage Server page, you can tell the wizard about an alternate configuration server to use in case the site to site VPN fails or is never established. When you publish a CSS, the information travels inside a TLS encrypted tunnel, so it’s safe to travel over the Internet. You publish the alternate main office CSS on the main office ISA Firewall, and the branch office ISA Firewall connects to the alternate CSS through that Server Publishing Rule. In order to use this feature, you need to install the CA certificate of the CA issuing the alternate CSS’s machine certificate in the branch office ISA Firewall’s Trusted Root Certification Authorities machine certificate store. Later in this series I’ll show you how to create an alternate CSS and publish it, and then configure the branch office ISA Firewall to use it, but at this time we have only a single CSS, so we’ll accept the defaults on this page and click Next.

Figure 13

1. On the Array Membership page, select the Join an existing array option. We already created an array for this branch office, so we can enable this option and choose that array. Click Next.

Figure 14

1. On the Join Existing Array page, enter the name of the array you want the branch office ISA Firewall to join. You might consider using the Browse button in this scenario, but you’ll quickly find that it doesn’t work. In this example, the name of the array we created for the branch office ISA Firewall is Branch, so we’ll enter that name. Click Next.

Figure 15

1. On the Configuration Storage Server Authentication Options page, select the Windows authentication option. We use this option because the branch office ISA Firewall will be joined to the domain. Not only does domain membership afford us a higher level of security and flexibility of deployment, it greatly simplifies our initial configuration by not requiring us to deal with certificates at this time. We’ll see how to work with certificates later, but it's good to know that we don’t have to worry about it now. Click Next.

Figure 16

1. Click Finish on the Completing the Create Answer File Wizard page.

Figure 17

1. Open the answer file (c:\IsaUsrConfig.inf) and take a look at it. Notice that everything here is in clear text, including administrative passwords, machine names, and account names. This is a very dangerous file in the wrong hands. For this reason, you need to think hard about how to handle this file. Remember that the file can be located on a USB key, on the root on the C: drive on the branch office ISA Firewall, or in a folder on the branch office ISA Firewall at c:\IsaAnswerFiles. You might want to include a procedure for the branch office user that runs the branch office connectivity wizard to delete this file via a shortcut on the desktop. Name it Activate Branch Office or something like that so the user doesn’t get curious. OK, I know this is kind of weak, but it's better than just letting the file sit on the branch office ISA Firewall’s hard drive any longer than it needs to be.

Figure 18

1. Copy the answer file to the root of the C: drive on the branch office ISA Firewall machine.

Run the Branch Office Connectivity Wizard at the Branch Office ISA Firewall

At this point you would ship the branch office ISA Firewall to the branch office. If a power user is responsible for installing the ISA Firewall, you should provide him with instructions on how to get things up and running. The power user should have the following information:

1. Provide the power user instructions on how to plug the power in, and where to plug in the internal and external interfaces and how to confirm that the internal and external interfaces are plugged into the correct ports.
2. The user name and password for a local administrator account. The user will need to log on as a local admin in order to run the wizard.
3. The procedures required to run the branch office connectivity wizard. The answer file will be automatically discovered and will have all the information required. The user just needs to click through the wizard according to your instructions
4. Include a link on the desktop that will do a DoD wipe of the installation file. You can use cipher.exe for this kind of wipe. Name the link something innocuous that won’t get the user’s attention or interest.
5. Include a link on the desktop that will delete the local admin account you created for the power user. Name the link something innocuous that won’t get the user’s attention or interest.
6. Have the power user call you after he completes the procedure, so that you can confirm that the installation file and the user account have been deleted.

Perform the following steps to run the branch office connectivity wizard on the branch office ISA Firewall:

1. Log on using the local admin account created on the branch office ISA Firewall. Open the Windows Explorer and go to the C:\Program Files\Microsoft ISA Server folder. Double click on the AppCfgWzd.exe program.

Figure 19

1. Read the information on the Welcome to the ISA Server Branch Office VPN Connectivity Wizard page, and then click Next.

Figure 20

1. On the Configuring Settings Source page, you’ll see that the wizard automatically finds the configuration file and automatically selects the From a file option. Confirm that the file name is correct and click Next.

Figure 21

1. On the Connection Type page, you’ll see that the wizard automatically detects that the VPN protocol to be used should be L2TP/IPSec. Click Next.

Figure 22

1. On the Array Server Deployment page, the This is the first server deployed in the array option is automatically detected from the answer file. Click Next.

Figure 23

1. On the Local Site to Site Authentication page, the user account that the main office will use to connect to the branch office ISA Firewall is automatically configured for you, based on the settings included in the answer file. Click Next.

Figure 24

1. On the Remote Site VPN IP Addresses page, the IP addresses representing the main office Network are automatically included and the IP address of the main office ISA Firewall is automatically configured in the Remote VPN server (IP address or name) text box. Click Next.

Figrue 25

1. On the Local Network VPN Settings page, the static address pool used to assign IP addresses to remote access VPN clients and VPN gateways is automatically configured. Click Next.

Figure 26

1. On the Remote Authentication page, the credentials that the branch office ISA Firewall will use to connect to the main office ISA Firewall are automatically entered. Click Next.

Figure 27

1. On the IPSec Authentication page, the pre-shared key configured in the configuration file is automatically detected and entered into the Use pre-shared key text box. Click Next.

Figure 28

1. Review the settings on the Ready to Configure the VPN Connection page and click Next.

Figure 29

1. On the Join Remote Domain page, the Join a domain option is automatically selected and the domain you configured in the configuration file is automatically entered into the text box. Click Next.

Figure 30

1. A dialog box appears informing you that the computer must be restarted after joining the domain. Click OK.

Figure 31

1. A Join Domain dialog box appears asking for credentials for a user with rights to join a computer to the domain. The credentials are automatically entered based on the information in the answer. Click OK.

Figure 32

1. The computer will automatically restart about a minute after clicking OK in the Join Domain dialog box.
2. Have the user log on as the local admin again. A minute or two after the desktop appears, the wizard will restart so that the branch office ISA Firewall can join the branch office array. There can be delays related to establishing the site to site VPN connection, so have the user wait about ten minutes before calling you with a problem statement.
3. The Resuming the ISA Server Branch Office VPN Connectivity Wizard page appears when the machine is ready to change from using it’s own CSS and using the CSS at the main office. Click Next.

Figure 33

1. On the Locate Configuration Storage Server page, the name of the main office CSS is automatically entered into the Configuration Storage server text box. The user account and credentials are automatically entered into the Connection Credentials section. Click Next.

Figure 34

1. On the Securely Published Configuration Storage Server page you have the option to enter an alternate CSS that can be used in the event that the site to site VPN connection goes down. In this example we’re not using an alternate CSS yet, so we’ll accept the default settings and click Next.

Figure 35

1. On the Array Membership page, the Join an existing array option is automatically selected. Click Next.

Figure 36

1. On the Join Existing Array page, the Branch array is automatically entered for you. Click Next.

Figure 37

1. On the Configuration Storage Server Authentication Options page, the Windows Authentication option is automatically selected for you. We want to use Windows Authentication because this machine is a domain member, which is an ISA Firewall security best practice. Click Next.

Figure 38

1. Review the settings on the Ready to Configure the ISA Server page and click Next.

Figure 39

1. A progress bar appears on the Configuring the ISA Server page. This phase can take a very long time, depending on the link speed and other factors. There have been several occasions where I’ve seen it take over 30 minutes for the site to site VPN connection establish successfully. Do not take the Event Viewer log entries at face value until you’ve waited at least a half hour for the connection to be established. If you find that the site to site VPN connection and the installation wizard fail in spite of waiting that long, then review the Event Viewer to being troubleshooting what the problem might have been.

Figure 40

1. The Completing the Appliance Setup Wizard page appears when the branch office ISA Firewall successfully switches from the local CSS to the main office CSS. Now you might be asking yourself "what is the appliance setup wizard" and that would be a good question, because we’ve been working with the branch office connectivity wizard up to now. I don’t have an answer for you, but I suspect that at one time the branch office connectivity wizard was named the appliance setup wizard, and then they later changed the name, but forgot to update this page. Regardless, this is the end of the wizard! Click Finish.

Figure 41

1. A dialog box will appear informing you that you need to restart the branch office ISA Firewall. Click OK.

Figure 42

1. Have the user log on using the local admin account that he’s been using up to this point. Instruct him to click on the link to the command files you created to delete the answer file and the user account you created for him. Then instruct him to log off. At this point the ISA Firewall at the branch office is configured and ready to run. Configuration and management can now be done at the main office CSS machine or any other machine you configure as a management station.

Summary

In this, part 5 of our article series, we completed the basic setup of the site to site VPN connection using the answer file together with the branch office connectivity wizard. In the next part of this series, we’ll manipulate the Firewall Rule set so that we can lock down communications between the branch office and the main office. We’ll create a rule set that allows the installation of a branch office domain controller and make configuration changes to DNS to support branch office name resolution. We’ll also configure the branch office ISA Firewall and DNS to support branch office Firewall clients, so that we’ll have fine tuned, granular access control over what branch office users can access at the main office and highlight how the ISA Firewall provides significantly more security than a conventional site to site VPN concentrator. See you then! –Tom.

[patris1]

http://www.isaserver.org/tutorials/Creating-VPN-ISA-2006-Firewall-Branch-Office-Connection-Wizard-Part6.html

PART-6


Beginning the advanced configuration settings to be used to join a branch office domain controller to a main office domain controller for intradomain communications.

Branch Office Domain Controller Scenario

In the first five parts of this series on how to create a site to site VPN between a main and branch office using ISA Firewalls, we focused on the issues related to creation and management of the site to site VPN connection itself. Now that we have the details of the site to site VPN connection created, we can tune the site to site VPN connection so that we control what moves over the VPN tunnel and get a much higher degree of security than what you can get with a typical VPN “concentrator” or “hardware” VPN gateway.

A good place to start this exercise on least privilege for branch office computer is to configure the branch office ISA Firewall to suppose intradomain communications between a branch office domain controller and the main office domain controller. Configuring the branch office ISA Firewall to support a branch office domain controller is a good example because we also need to carry out a number of other configuration steps to make a branch office domain controller work.
In this article, I hope to complete the following steps:

• Disable DDNS on the Demand-dial Interfaces and the Main and Branch Office ISA Firewalls
• Enable DDNS on the msfirewall.org Forward and Reverse Lookup Zone
• Create the Intradomain Communications Access Rule on the Branch Office ISA Firewall

Disable DDNS on the Demand-dial Interfaces and the Main and Branch Office ISA Firewalls

Remember way back in the first or second article in this series where we disabled DDNS on the msfirewall.org forward lookup zone? Do you remember why we did this? To refresh your memory, we disabled DDNS on the msfirewall.org forward lookup zone because we wanted to prevent the ISA Firewall at both the main and branch offices from registering their demand-dial interface IP address with DNS. When the demand-dial interfaces register with the DDNS, it causes all sorts of problems because clients resolve the names of the ISA Firewalls to their demand-dial interface addresses instead of their actual IP addresses.
At that time I asked you if we really needed to do this. Wouldn’t it be better if there was some way we could configure the demand-dial interfaces themselves so that they wouldn’t register their addresses in the DDNS? That would be a much better solution, since it's very inconvenient to keep DDNS disabled on the DNS server in our organization. Not only is it inconvenient, it’s often unrealistic to do so.
The good news is that we can disable automatic DNS registration on the demand-dial interfaces for both the main and branch office ISA Firewalls using the RRAS console. In general, we need to avoid making changes to the VPN configuration on ISA Firewalls using the RRAS console, because settings made in the ISA Firewall console will overwrite changes we make in the RRAS console. The good news here is that changing the DDNS registration for the demand-dial interface is not overwritten by the ISA Firewall VPN configuration.
Perform the following steps at the main office ISA Firewall:

1. Click Start, point to Administrative Tools and click Routing and Remote Access.
2. In the Routing and Remote Access console, expand the server name.
3. Click on the Network Interfaces node in the left pane of the console. Right click on the Branch entry in the right pane of the console and click Properties.

Figure 1

1. In the Branch Properties dialog box, click the Networking tab and then click the Properties button.

Figure 2

1. On the Internet Protocol (TCP/IP) Properties dialog box, click the Advanced button.

Figure 3

1. In the Advanced TCP/IP Settings dialog box, click the DNS tab. On the DNS tab, remove the checkmark from the Register the connection’s addresses in DNS checkbox. Click OK.

Figure 4

1. Click OK in the Internet Protocol (TCP/IP) Properties dialog box. Click OK in the Branch Properties dialog box. If the demand-dial interface is currently connected, you may see a dialog box informing you that the changes will not take effect until the next time the demand-dial interface is connected.
2. Close the Routing and Remote Access console.

Perform the following steps at the branch office ISA Firewall:

1. Click Start, point to Administrative Tools and click Routing and Remote Access.
2. In the Routing and Remote Access console, expand the server name.
3. Click on the Network Interfaces node in the left pane of the console. Right click on the Branch entry in the right pane of the console and click Properties.

Figure 5

1. In the Main Properties dialog box, click the Networking tab and then click the Properties button.

Figure 6

1. On the Internet Protocol (TCP/IP) Properties dialog box, click the Advanced button.

Figure 7

1. In the Advanced TCP/IP Settings dialog box, click the DNS tab. On the DNS tab, remove the checkmark from the Register the connection’s addresses in DNS checkbox. Click OK.

Figure 8

1. Click OK in the Internet Protocol (TCP/IP) Properties dialog box. Click OK in the Branch Properties dialog box. If the demand-dial interface is currently connected, you may see a dialog box informing you that the changes will not take effect until the next time the demand-dial interface is connected.
2. Close the Routing and Remote Access console.
3. Restart both the main and branch office ISA Firewalls and wait for the demand-dial site to site VPN connection to establish.

Enable DDNS on the msfirewall.org Forward and Reverse Lookup Zone

Now that we have the DDNS problem solved for the demand-dial interfaces, we can enable DDNS for the msfirewall.org zone. DDNS is helpful in general, and will be especially helpful in particular, since we want the branch office domain controller to automatically register all of its domain related DNS records in the main office DNS. We could create those records manually, but that incurs a lot of administrative overhead and increases the risk of making an error.
Go to the domain controller at the main office and perform the following steps:

1. At the main office domain controller, click Start and point to Administrative Tools. Click on DNS.
2. In the DNS console, expand the server name and then expand the Forward Lookup Zones node.
3. Click the msfirewall.org node and then click Properties.

Figure 9

1. In the msfirewall.org Properties dialog box, click on the General tab. On the General tab, click the down arrow in the Dynamic updates drop down list and select the Secure only option. This allows only domain members to enter their entries in the DDNS. Click OK.

Figure 10

1. Right click on the DNS server name in the left pane of the console and point to All Tasks, then click on Restart.

Figure 11

Create the Intradomain Communications Access Rule on the Branch Office ISA Firewall

With the background work done, we can now move on to the ISA Firewall configuration. What we need to do first is to create a rule that allows the branch office domain controller to use the intradomain protocols required to communicate domain activity with other domain controllers. In this example, with a domain controller at the main office.
The table below shows the conventional intradomain protocols Access Rule settings:

Name
Branch DC > Main DC
Action
Allow
Protocols
Microsoft CIFS (TCP 445)
DNS
Kerberos-Adm(UDP)
Kerberos-Sec(TCP)
Kerberos-Sec(UDP)
LDAP (TCP)
LDAP (UDP)
LDAP GC (Global Catalog)
RPC (all interfaces)
NTP
Ping
From
Branch Office DC
To
Main Office DC
Users
All
Schedule
Always
Content Types
All content types
Table 1: Protocols Required for Intradomain Communications I should note here that this isn’t the only approach we can take to allowing intradomain communications from the branch office to the main office domain controller. This approach focuses on controlling traffic that moves from the branch office to the main office and assumes that all traffic is allowed from the main office to the branch office. While I wouldn’t say that this is the optimal approach (and we’ll change the main office Access Rules later), it does highlight what I consider to be the best approach to controlling access: the higher risk location is the branch office and therefore we should focus our attention on controlling what moves between the branch offices to the main office.
On the other hand, you could set access policy at the main office and focus your attention on the main office ISA Firewall and create Access Rules there to control what can come in from the branch offices.
Probably the best, and most scalable method for controlling access between branch offices and the main office is to use Enterprise Policies. When you create an Enterprise Policy, you can assign that policy to each array that represents each branch office installation. This greatly simplifies management of firewall policy for branch offices, since you can make changes to the enterprise policy once and those changes are automatically propagated to all branch office arrays.
In this example, we’ll use an Enterprise Policy to demonstrate how Enterprise Policies work. To the best of my knowledge, this is the first time there has been a discussion or demonstration of enterprise policies in a public forum, so welcome to this new groundbreaking achievement!
The first step is to create a new Enterprise Policy. We need to create the new Enterprise Policy because we can’t make any changes to the default Enterprise Policy. After we create the new Enterprise Policy, we can create an Access Rule that can be applied to all arrays to which this Enterprise Policy is defined. The last step is to bind the Enterprise Policy to the branch office ISA Firewall array.
Perform the following steps at the CSS machine to create the Enterprise Policy:

1. At the CSS machine at the main office network, open the ISA Firewall console.
2. In the ISA Firewall Console, expand the Enterprise node and then expand the Enterprise Policies node. Click on the Enterprise Policies node and then right click on it. Point to New and click Enterprise Policy.

Figure 12

1. On the Welcome to the New Enterprise Policy Wizard page, enter a name for the Enterprise Policy in the Enterprise Policy text box. In this example, we’ll name the policy Branch Policy and click Next.

Figure 13

1. Click Finish on the Completing the New Enterprise Policy Wizard page.

Figure 14

1. Click on the Branch Policy node in the left pane of the console, then click on the Tasks tab in the Task Pane. On the Task Pane, click the Create Enterprise Access Rule.
2. On the welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we want to create an Access Rule that will allow the branch office domain controllers to connect to the main office domain controller. For this reason, we’ll name the rule Branch DCs >5 Main DC. Click Next.

Figure 15

1. On the Rule Action page, select the Allow option and click Next.

Figure 16

1. On the Protocols page, confirm that the Selected protocols option is selected from the this rule applies to drop down list. Then click the Add button. In the Add Protocols dialog box, click on the All Protocols folder. Double click on each of the protocols listed in Table 1 above, then click Close.

Figure 17

1. Click Next on the Protocols page.

Figure 18

1. On the Access Rule Sources page, click the Add button. In the Add Network Entities dialog box, click the New menu and then click Computer Set. In the New Computer Set Rule Element dialog box, enter Branch Office DCs in the Name text box.

Figure 19

1. Click the Add button in the New Computer Set Rule Element dialog box and click the Computer entry in the list.

Figure 20

1. In the New Computer Rule Element dialog box, enter the name of the branch office computer in the Name text box. In this example our branch office computer name will be named Branch1 DC, which will help us differentiate this DC from other branch office DCs. Enter the IP address of our branch office domain controller in the Computer IP Address text box, which in this example is 10.0.1.2. Click OK.

Figure 21

1. Click OK in the New Computer Set Rule Element dialog box.

Figure 22

1. In the Add Network Entities dialog box, click on the Computer Sets folder and then double click on the Branch Office DCs entry. Click Close in the Add Network Entities dialog box.

Figure 23

1. Click Next on the Access Rule Sources page.

Figure 24

1. On the Access Rule Destinations page, click the Add button. In the Add Network Entities dialog box, click the New menu and click the Computer entry.

Figure 25

1. In the New Computer Rule Element dialog box, enter a name for the computer in the Name text box. In this example, we’re entering the name of the main office domain controller, so we’ll name it Main Office DC. Enter the IP address of the main office domain controller in the Computer IP Address text box, then click OK.

Figure 26

1. In the Add Network Entities dialog box, click the Computers folder and then double click on the Main Office DC entry. Click Close.

Figure 27

1. Click Next on the Access Rule Destinations page.

Figure 28

1. On the User Sets page, accept the default setting All Users. The reason we need to allow all users is that domain controllers don’t have logged on users and that in order to authenticate, you need the Firewall Client, and the Firewall client should never be installed on a domain controller. Click Next.
2. Click Finish on the Completing the New Access Rule Wizard page.
3. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

Now that the Enterprise Policy is configured, the next step is to bind this Enterprise Policy to the branch office array. At this time, the default Enterprise Policy is bound to the branch office array. We will change things so that the Branch Policy is bound to the branch office array.
Perform the following steps to bind the Branch Policy Enterprise Policy to the Branch array:

1. In the ISA Firewall console, expand the Arrays node and then click on the Branch node. Right click on the Branch node and click Properties.

Figure 29

1. In the Branch Properties dialog box, click the Policy Settings tab. On the Policy Settings tab, click the drown arrow for the Enterprise policy list. Select the Branch Policy option. This will import and apply the rules defined in the Enterprise Policy into the array policy. We’ll also remove the checkbox from the Publishing rule (“Deny” and “Allow”) so that Web and Server Publishing Rules can’t be created at the branch office, which is something we’d really like to avoid for security reasons. Click OK.

Figure 30

1. Expand the Branch array in the left pane of the console and click the Firewall Policy (Branch) node. Notice that the Access Rule we created at the Enterprise Policy level has been applied to the array policy.

Figure 31

1. We want this domain controller policy to always be applied before the local array policy. In order to do this, click on the Branch Policy Enterprise Policy node in the left pane of the console. Right click on the Branch DCs > Main DC Access Rule and click the Move Up command.

Figure 32

1. Click on the Firewall Policy (Branch) array policy. You’ll now see that the Enterprise Policy will be applied before the local array policy.

Figure 33
As you can see from configuring the Enterprise Policy, it will be a lot easier to apply policies to multiple branch offices by making changes once to the Branch Policy Enterprise Policy and having those changes automatically propagated to all arrays to which this policy is bound. This is a lot easier than having 30 arrays and having to make the changes to each one of them. For example, as we add more branch office domain controllers, all we need to do is update the Computer Set Branch Office DCs and the rule will be applied to those new DCs at the branch offices.

Summary

In this, part 6 of our series on using the site to site VPN branch connectivity wizard to connect branch offices to the main office, we began our advanced configuration settings that we will use to join a branch office domain controller to a main office domain controller for intradomain communications. A groundbreaker event took place during this article, were I demonstrated how to create an Enterprise Policy and how to use that Enterprise Policy to streamline policy development and deployment for a distributed enterprise firewall deployment. In the next part of this series, we’ll run depromo on the branch office domain controller, install an Active Directory integrated DNS server on the branch office domain controller, and then change the DNS settings on the branch office ISA Firewall.
After the branch office domain controller is installed, the next step is to create a firewall policy for the branch offices that will allow them access to resources at the main office. We’ll create a customized user/group based policy that will allow users access to Exchange Server resources at the main office, and more. If there’s time, we’ll also begin the configuration of an alternate CSS so that we have fault tolerance for our ISA Firewall Enterprise configuration.

[patris1]

http://www.isaserver.org/tutorials/Creating-VPN-ISA-2006-Firewall-Branch-Office-Connection-Wizard-Part7.html

PART-7


A look at some of the effects RPC communications have through the ISA Firewall.

Branch Office Domain Controller Scenario

Thanks for coming back for more of my series on creating a site to site VPN network using the ISA Firewall. Last week we created Enterprise Policies that will allow us to put up a domain controller in the branch office. Last week’s article was a special event for us on ISAserver.org, since it was the first time ever in a public forum that there was a discussion and examples of how to use and create Enterprise Policies that enable you to push firewall configuration automatically to a worldwide deployment of ISA Firewall arrays. If you missed that article, check it out now!

At this point we have the site to site VPN working smoothly and we’re ready to deploy the branch office domain controller. Once we get the branch office domain controller online, we can install an Active Directory integrated DNS server on that DC and configure the branch office ISA Firewall to use that DNS server as its primary DNS server. This helps break the dependence on the site to site VPN connection for DNS service availability.
In this week’s article we’ll look at some of the effects RPC communications have through the ISA Firewall. This article is a little different, in that we’ll have more questions left unanswered than answered. However, I hope that by bringing these issues to the light of day, we will be able to harness the collective knowledge and experience of the ISA Firewall community to come up with answers to some of these questions.
Disable Strict RPC Compliance on the Intradomain Communications Rule

A common problem seen when communications take place through the ISA Firewall is that autoenrollment does not work correctly. Another problem that appears to be closely related to that one is that the Certificates MMC snap-in doesn’t work. There is a KB article indicating that if we disable strict RPC compliance on our Access Rule, then the RPC communications required for autoenrollment and the Certificates MMC will work. I have to tell you, in my experience, I’ve never seen this work. However, I have heard from other people that they actually have seen this work. Because of this, we’ll give it a try in our lab environment and see what happens.
We want certificate autoenrollment to work because we have an enterprise CA installed on the main office domain controller. Because we have a enterprise CA in place, this allows us to have the CA certificate of the enterprise CA automatically placed in the Trusted Root Certificate Authorities machine certificate store of all domain members. This is a great convenience, since it allows all our domain members to automatically trust the certificates issued by our enterprise PKI.
Perform the following steps to disable strict RPC compliance on our intradomain communications Access Rule:

1. In the ISA Firewall console, expand the Enterprise node and then expand the Enterprise Policies node. Click the Branch Policy node. Right click the Branch DCs > Main DC Access Rule and click Configure RPC protocol.

Figure 1

1. In the Configure RPC protocol policy dialog box, remove the checkmark from the Enforce strict RPC compliance checkbox. Click OK.

Figure 2

1. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

Some people have asked me whether we should re-enable strict RPC compliance after we install the branch office DC. I don’t have a definitive answer for this, as the exact details of what this setting does are not publicly available. I think it’s safe to assume that it's more secure to have strict RPC compliance enabled, but if this security feature breaks core functionality, and since the security benefits have not been articulated anywhere in a public forum, then our best choice is to disable this feature and obtain the functionality benefits.
However, the final decision is up to you. If you don’t need autoenrollment to work (and we haven’t demonstrated yet for sure whether autoenrollment will work when this feature is disabled) then you might want to leave strict RPC compliance in place.
Bottom line is that there is no hard and fast right or wrong answer here, which is the case for most security related decisions.
Run DCPromo on the Branch Office Domain Controller Machine

Now we’re ready to install the domain controller at the branch office. How you accomplish this task depends on your environment. Many companies that I’ve worked with will create a lab environment with an IP addressing scheme that mirrors the branch office deployment and install and configure the DC at the main office before shipping it to the branch office. Other companies that I’ve worked with will ship the DC machine to the branch office and then have main office IT personnel visit the branch office to setup the DC.
There are advantages and disadvantages to each option. I personally prefer to send an IT pro to the branch office, since DC deployment is critical and it’s often best to have someone on site who can troubleshoot potential problems.
Perform the following steps to install the DC on the branch office domain controller machine:

1. Click Start, click Run and enter dcpromo in the Open text box. Click OK.
2. Click Next on the Welcome to the Active Directory Installation Wizard page.
3. Read the information on the Operating System Compatibility page and click Next.
4. On the Domain Controller Type page, select the Additional domain controller for an existing domain option and click Next.

Figure 3

1. On the Network Credentials page, enter the credentials of a user who has permission to install new domain controllers and click Next.

Figure 4

1. On the Additional Domain Controller page, click the Browse button and click the name of the main office domain. In this example, the name of the domain is msfirewall.org, so we’ll select that domain from the list in the Browse for Domain dialog box. Click OK and then click Next.

Figure 5

1. On the Database and Log Folders page, accept the defaults and click Next.
2. On the Shared System Volume page, accept the default location and click Next.
3. Enter a password and confirm the password on the Directory Services Restore Mode Administrator Password page and click Next.
4. Click Next on the Summary page and click Next.
5. The installation wizard starts. Let it continue until you see the completion page.

Figure 6

1. Click Finish on the Completing the Active Directory Installation Wizard page.

Figure 7

1. Click the Restart Now button in the Active Directory Installation Wizard dialog box.

The Dcpromo process worked flawlessly! There were no errors during installation and the machine rebooted and everything appeared to work OK. If you open up the Certificates MMC you’ll see that the enterprise CA certificate is automatically populated in the Trusted Root Certification Authorities certificate store, just as we wanted, as seen I the figure below.

Figure 8
However, if we open the Event Viewer, we’ll see some errors that may indicate some real problems. The figure below shows that autoenrollment didn’t work and the branch office DC did not receive a DC certificate. Is this a real error? Is this a real problem? Is this a problem related to the ISA Firewall?

Figure 9
The figure below shows another error that might be significant. This error indicates that the branch office domain controller cannot query for a list of group policy objects. This sounds like a big problem. Is it? Is it a problem with the ISA Firewall? Is it an indication of another problem?

Figure 10
The figure below shows an error indicating that DCOM was unable to communicate with the domain controller at the main office (dc.msfirewall.org). Is this a problem with the ISA Firewall? Something else?

Figure 11
But are these errors actually true? Perhaps they were generated at a point in time during startup before the site to site VPN was activated? I considered this, but I confirmed that the site to site VPN was up and functional during system startup for the branch office DC.
Are we sure that autoenrollment doesn’t work? We saw that the CA certificate was automatically populated in the Trusted Root Certification Authorities certificate store. Should there be a DC certificate automatically assigned? Or do we need to create a policy for this to happen?
As for group policy processing, is it actually true that group policy isn’t being processed?
To test this, make a small change to Domain Group Policy at the main office domain controller. For example, go to the Desktop node in the Administrative Templates section in the User Configuration section, as seen in the figure below.

Figure 12
Next, double click the Remove Recycle Bin icon from desktop entry in the right pane and click the Enable section. Click OK and then run the gpupdate /force command at the main office domain controller. After that completes, run the gpupdate /force command at the branch office. What happens?

Figure 13
From my testing and experience, group policy is applied at both the main and branch offices, and the recycle bin object is removed from the desktop (you might have to refresh the desktop to see this change). So, we’ve learned the lesson, once again, that we can’t always trust what we see in the Event Viewer.
How about the Certificates MMC? Unfortunately, the Certificates MMC doesn’t work, in spite of the comments made in the KB article at "The certificate request failed because of one of the following conditions" error message when you request a certificate in ISA Server 2004. However, perhaps I haven’t completely configured the ISA Firewalls to meet the specifications in that KB article. Here are the salient instructions from that KB article:
“To request a certificate for the ISA Server computer, click to clear the Enforce strict RPC compliance check box in the System Policy Editor dialog box. However, to request a certificate for a client computer when the client computer and the Certification Authority are on different networks, you do not have to modify the system policy on the ISA Server computer. In this scenario, you must modify the strict RPC-compliance settings for the rule or rules that permit traffic between the two networks. To do this, follow these steps:

1. Start the ISA Server Management tool.
2. Expand the ServerName node, and then click Firewall Policy.
3. Right-click the rule that permits traffic between the network where the Certification Authority resides and the network where the client computer resides.
4. Click Configure RPC Protocol.
5. Click to clear the Enforce strict RPC compliance check box, and then click OK.
6. Repeat steps 3 through 5 to modify system policy rules and to permit DCOM communications between any other rules that are between two particular networks.
7. When you have finished modifying policy rules, click Apply

Notice step 6, which is something I find really interesting. How would system policy be involved with any other rules that are between two particular networks? What does this mean? Does it mean System Policy rules that apply to communications between two ISA Firewall Networks? How can this be? System Policy only controls traffic that either sources from the ISA Firewall or is directed to the ISA Firewall. How then could a System Policy Rule control traffic between two networks.
Perhaps this is some sort of secret hint that is being delivered to us from the ISA sustained engineering group? In order to test this hypothesis, let’s see what happens if we disabled strict RPC compliance at the System Policy level. The only way to do this is to open the System Policy editor at the array level.
Click on the Firewall Policy in the left pane of the ISA Firewall console and then click on the Tasks tab in the Task Pane. In the Task Pane, click the Edit System Policy link. Click on the Authentication Services policy group in the left pane and then remove the checkmark from the Enforce strict RPC compliance checkbox. Click OK. Perform this action on both the ISA Firewalls.

Figure 14
In order to test this, I restarted both the ISA Firewalls to make sure that the RPC state table entries were removed. I don’t know if that’s required, but it’s the most reliable way to confirm that the tables are cleared. I also restarted the branch office domain controller. The result? The Certificates MMC failed to connect to the enterprise CA. You will see the error below:

Figure 15
Both of the reasons mentioned in the error are incorrect. The CA was online and I was logged on as an enterprise administrator. A look at the branch office ISA Firewall’s real time log viewer shows us some hints that the RPC filter is the problem:

Figure 16
These log file entries were taken when the certificate request was sent from the branch office domain controller to the main office DC, which is also an enterprise CA. The only conclusion we can come to, at least in my studies, is that the recommendations in the KB article at "The certificate request failed because of one of the following conditions" error message when you request a certificate in ISA Server 2004 are incorrect, or there is some vagary in my lab environment, using VMware workstation, that prevents this from working correctly. If you have got this to work correctly, please write to me at tshinder@isaserver.org and let me know.
What are my conclusions? First, do what is recommended in the KB article. Microsoft would not publish this article unless they have strong evidence that the configurations they describe actually work. Second, Group Policy processing seems to work fine, so you don’t need to worry about that. Third, I’m still not sure if autoenrollment isn’t working, as I haven’t set up an autoenrollment policy in Group Policy and I’m not sure if domain controllers are automatically assigned machine certificates (OK, this is my bad – I should know this but haven’t been able to find information on this issue yet).

Summary

In this article we spent some time examining what happens when we install a DC at the branch office. Unfortunately, there are more questions than answers at this point. Microsoft documentation states that all of our troubles should be solved by disabling strict RPC compliance, but we continue to see a number of RPC related communications errors in the Event Viewer. Can we believe what we see in the Event Viewer? It suggests that Group Policy processing doesn’t work, but we can see that Group Policies are applied. What about autoenrollment? Perhaps we need to create a policy first. And then there is the Certificates MMC issue.
We have more questions than answers at this time, but can say that for the most part, our domain controller seems to be working properly. Next week we’ll configure an Active Directory site for the branch office and configure the site link. We’ll also create a DNS server on the branch office DC and change the DNS settings on the ISA Firewall. See you then! – Tom.