If you would like to read the other parts in this article series please go to:
- Test Lab Guide: Demonstrate Site to Site VPN with Threat Management Gateway 2010 (Part 1)
- Test Lab Guide: Demonstrate Site to Site VPN with Threat Management Gateway 2010 (Part 2)
- Test Lab Guide: Demonstrate Site to Site VPN with Threat Management Gateway 2010 (Part 4)
In the first part of this Test Lab Guide module series on how to configure the TMG firewall as a site to site VPN gateway, we first configured the main office TMG firewall as a VPN gateway by setting up a remote site network using the site to site VPN wizard. We also created an account on the main office TMG firewall that the branch office TMG firewall can use to authenticate when calling the main office TMG firewall VPN gateway. In the process of creating the remote site network, a Network Rule was created that established a route relationship between main and branch office TMG firewalls and a Firewall policy Access Rule was created that allowed all traffic between the main and branch office networks.
In the second part of the series, we installed the operating system on the branch office TMG firewall and renamed the TMG branch office firewall to TMGBRANCH. The TMG firewall was configured with two virtual NICs: one that is connected to the Internet subnet and one that is connected to a new virtual network, which we named BRANCHNET. Next, we installed the TMG firewall software on the TMGBRANCH virtual machine and completed the initial configuration of the TMG firewall software.
In this, part three of the 4 part Test Lab Guide series on how to configure the TMG firewall as a site to site VPN gateway, we will install a new server on the branch office network, which will provide DHCP services that will support clients that are connected to the BRANCHNET virtual network and will also support addressing requirements for the VPN server component of the TMG site to site VPN gateway. As we will explain in more detail later, we’re going to do this because it’s a more realistic scenario to have a DHCP server at the branch office, and also because we can solve some specific routing issues when we assign VPN clients’ addresses via DHCP rather than using a static address pool.
Install and Configure the Operating System and Configure DHCP on BRANCHSVR1
So let’s get started! We will install a server located behind the TMGBRANCH firewall and install and configure DHCP services on that machine. We’re doing this to get around some potential routing and addressing issues that are related to the definition of TMG Firewall Networks and how VPN clients are assigned addresses. The reason for this is that if you define a static address pool for VPN clients, you are going to need to move those addresses out of the default Internal Network definition. That means that not all of the addresses we defined as part of the branch office network on the main office TMG firewall (TMG1) will be considered part of the default Internal Network on the TMGBRANCH firewall, which can create some issues with routing rule and firewall rules. Since just about all branch offices out in the “real world” are going to have a DHCP server anyhow, it’s also more realistic for us to install a DHCP server on our branch office network in the test lab.
Again, I won’t go over how to install the Window Server 2008 R2 Enterprise Edition operating system, because you already know how to do that. Below are some key configuration tasks to carry out after the OS installation completes:
- The server will have a single NIC – you need to connect that NIC to the BRANCHNET virtual network
- Rename the server to BRANCHSVR1
- Assign the local administrator account the password p@ssword1
Here is the IP addressing information for BRANCHSVR1:
IP Address: 10.0.1.2
Subnet Mask: 255.255.255.0
Default Gateway: 10.0.1.1
DNS Server: (none)
After renaming the server and configuring its IP addressing information, you’ll be ready to install and configure the DHCP service. Open the Server Manager console and click on the Roles node in the left pane of the console. In the right pane of the console, click the Add Roles link that’s shown in Figure 1.
On the Before You Begin page, which you can see in Figure 2, click Next.
On the Select Server Roles page that’s shown in Figure 3, put a checkmark in the DHCP Server checkbox, then click Next.
On the Introduction to DHCP Server page, which you can see in Figure 4, click Next.
On the Select Network Connection Bindings page that’s shown below in Figure 5, make sure there is a checkmark in the 10.0.1.2 checkbox. This should be enabled automatically, but it’s always best to make sure. Then click Next.
On the Specify IPv4 DNS Server Settings page, which you can see in Figure 6, you have the option to enter a Parent Domain, Preferred DNS server IPv4 address and Alternate DNS server IPv4 address options. For the purposes of this Test Lab Guide, we won’t need DNS services at the branch office, because we’re going to use IP addresses to test the connectivity between the branch and main offices. However, in a production environment, it is likely that you would have a DNS server at the branch office, so you would want to put in DNS server settings for DHCP scope options at your branch office. This time, though, make no changes on this page; just click Next.
On the Specify IPv4 WINS Server Settings page that you see in Figure 7, select the WINS is not required for application on this network option. Since we don’t have a WINS server on this network, there’s no reason to enable this DHCP option. Click Next.
On the Add or Edit DHCP Scopes page that you see in Figure 8, you will enter the list of IP addresses that will be available to your DHCP clients when they are connected to the BRANCHNET subnet. Click Add and then enter the following information:
- Scope name: BranchNet
- Starting IP address: 10.0.1.100
- Ending IP address: 10.0.1.150
- Subnet mask: 255.255.255.0
- Default gateway (optional): 10.0.1.1
After entering these values, click OK.
The IP addressing range now appears in on the Add or Edit DHCP Scopes page that you see in Figure 9. You should see the range 10.0.1.100-10.0.1.150 in the IP address range section. Double check that and then click Next.
On the Configure DHCPv6 Stateless Mode page that you see in Figure 10, select the Disable DHCPv6 stateless mode for this server option, then click Next.
On the Confirm Installation Selections page that is shown in Figure 11, review the settings for the DHCP server to ensure you have them right, and then click Install.
On the Installation Results page that you can see in Figure 12, confirm that you see the message that the Installation succeeded in the results page. Then click Close.
Back in the Server Manager console, expand the Roles node and then expand DHCP server. Next, expand IPv4 and then expand Scope. Now click Address Pool. In the right pane of the console,you shoudl see the address range that you assigned to this scope.
In this, part 3 of the four part Test Lab Guide module series on how to configure the TMG firewall as a site to site VPN server, we installed an additional server on the branch office network that will act as a DHCP server for that network. We did this because it is more realistic, in that most branch offices are going to have their own DHCP servers and also it addresses a minor complication with routing issues that occurs when you use DHCP provided addresses instead of a static address pool to support VPN clients (which includes the VPN “client” that represents the other site to site VPN gateway).
In a production network you can work around these issues, but for the sake of simplicity in demonstrating site to site VPN connectivity using a TMG firewall in this test lab, we decided to use DHCP. In addition, most organizations are likely to use DHCP to support VPN connectivity, so that is another good reason that we did things the way we did here. In the next and final part of this series, we will configure the remote site network on the branch office TMG firewall (TMGBRANCH), which will enable it to connect to the main office TMG site to site VPN server. Then we will test the configuration and confirm that it works correctly. We will also look at some logging and monitoring features that will help us to understand how the configuration works so that you can recognize normal vs. abnormal operations. See you then! –Deb.
If you would like to read the other parts in this article series please go to: