Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard (Part 6)

If you missed the other parts in this article series, check them out at:

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.

Discuss this article

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

Discuss this article

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.

Discuss this article

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.

If you missed the other parts in this article series, check them out at:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top