In this post I will be installing a TMG Array as a “back firewall” behind a hardware firewall. The Array will consist of two virtual servers, TMG01 and TMG02 which each have 3 NICs. One NIC will be dedicated to the LAN network, accessible internally. One NIC will be dedicated to the DMZ network, accessible to the outside world on a static mapped IP. The third NIC will be a dedicated intra-array communications NIC as per Microsoft’s recommendation.
Both TMG servers will be domain joined – there are several reasons for this, not least of which is that we require integrated authentication for the proxy clients.
The array will be a Network Load Balanced proxy server for all LAN clients to access the internet; it will provide content caching and malware protection. It will also reverse proxy Outlook Web Access, ActiveSync, Outlook Anywhere, SharePoint and some internal static HTTP resources. It will also provide SSL VPN (SSTP) access for remote clients, but that will be the subject of a later post.
The network diagram for this setup looks like this:
Prior to installation, it’s important to get the network adaptors configured correctly, the reasons for which are discussed later in more detail, but the basic rule is that there should only be one default gateway and one adaptor configured to provide DNS resolution to the internal network.
Run the following procedure on BOTH servers.
Configure all 3 NICs with their assigned IP addresses.
Run the TMG 2010 installer, ensure you’ve run Windows Update and you’re fully patched.
Run the Preparation Tool, which basically installs pre-requisites and checks for required Roles and Features. Correct anything that’s not installed.
Launch the Forefront Configuration Wizard
Accept the license agreement
Enter the product license details
Select the option to install
Install path (this is not where the proxy cache is stored, configure that later!)
Configure the Internal network IP address ranges.
Accept the services warning
Since there are domain controllers in other network ranges for this domain, TMG will create a system policy for AD connections to all the IP addresses of Domain Controllers. It will also create a management access rule for the workstation IP that is connected
Click Install to begin the installation – this takes a while!
After about 40 minutes, you reach the completion screen.
While that’s installing, you can set up the required DNS records.
proxy (or whatever you want to call the proxy NLB!)
*created automatically as they’re domain joined with AD integrated DNS
The additional records here are for the NLB virtual IP address (proxy.domain.com) and for the Intra-array communications network. The intra-array DNS records are required because of the Kerberos dependency to access the Array Configuration Storage Server (CSS); it requires a SPN (Service Principle Name) to be configured, which in turn requires DNS resolution.
Both TMG servers should be updated to the latest SP level.
The service pack installer must be run from an elevated command prompt, otherwise it will fail.
Run the SP installation
Accept the license agreement
Select the server, and the credentials
Run the installation
If you receive any errors or warnings, the chances are you’ve not run the installation from an elevated command prompt. You need to re-run the SP to install correctly.
Restart the server (it now seems to take a lot longer to reboot the servers – be patient!)
When you run the Forefront Threat Management Console for the first time it will run the Getting Started Wizard
Click, Configure network settings – start the network setup wizard
Select the correct network template – for this setup it’s Back Firewall
Select the network adaptor for the LAN network – this is where some network routing information is required. TMG should not have multiple default gateways, just one “gateway of last resort”. In this case it should be the address of the Front firewall on the DMZ, because that’s where we want to route anything that is not on our internal network. This means that we need to add a route for all INTERNAL networks that we want to route via the gateway for the internal network. This depends on the topology of the network TMG is installed in. DNS is configured on the interface closest to your internal DNS that is capable of resolving external namespaces. Routing is configured in the next section.
Select the network adaptor for the perimeter network, and set the type of IP addresses to use (in this setup Private as there is the Front firewall between the External network and the DMZ: there will be Network Address Translation between the two and we need to avoid “double-NATing” ).
Finish the wizard and run the “configure system settings” wizard As the machine is already named and part of the Domain, there’s no need to change any of the current settings – click through to finish
Now run the “define deployment options link and set the Microsoft Update, then Network Inspection and Web Protection settings, CEIP settings, and feedback. I kept the defaults here, they can be changed later if required.
The wizard is now complete, aside from the web access wizard which when you click close.
Configure the Web Access Policy Wizard
Create the default web access URL categories
Add any non-default URLs you wish to block
Configure any unrestricted users, if required.
Enable/disable Malware Inspection, depending on your license.
Configure HTTPS inspection – we will allow users to establish HTTPS regardless. You can configure to block invalid HTTPS certificates.
Configure the Web Cache – best practice is to use a non-system drive for caching
Review and finish the setup
Check “Save the changes and restart the services”
With the additional subnets in the network, the TMG servers need to know where to route traffic, which interface they are to route the traffic on, and how to treat the network. The routing is easiest to configure at the server level using the ROUTE command.
View the routing table using the “route print” command from an elevated command prompt.
You can see the default route, or gateway of last resort is set to 192.168.10.1 – the DMZ gateway. You can also see the server has a route for the networks it has an IP address on; namely the LAN and Intra-array networks (192.168.8.0/24 and 10.20.200.0/29). These are “On-Link”, meaning anything for those networks will be sent via the NIC with the IP address on the same subnet.
The problem with this configuration as it stands is that the server can only route internal networks that it has an IP address on, or send it to the default gateway on the DMZ. When you try and access an internal network (e.g. 10.20.110.0, which for me is the the client network), the only route it has is the default gateway in the DMZ which does not have access to the internal LAN.
To correct this we add a route for each internal network, specifying the correct gateway and interface.
route add –p [network IP] MASK [subnet mask] [gateway IP] METRIC [metric] IF [Interface]
“Route add” is self-explanatory, “–p” sets the route as persistent across reboots. For the client network above, [network IP] is 10.20.110.0 and the [subnet mask] is 255.255.254.0. The gateway needs to be the gateway for the network that the LAN NIC is on – 192.168.8.1. The metric is the priority if the gateway, lower numbers are a higher priority – I am using 20. To find the [interface] the easiest way to be sure is to check the network adaptors properties and make a note of the MAC address, and then compare it to the Interface List in the route show command. The LAN NIC is interface 11 in this configuration. The final route command looks like this:
route add –p 10.20.110.0 mask 255.255.254.0 192.168.8.1 metric 20 if 11
You can now test the route by pinging a host on the new subnet. Add routes for all internal networks you want routed through the LAN interface.
CSS access over the Intra-array network requires Kerberos, which requires SPNs. To create the SPNs, run a command prompt and issue these commands (per server):
setspn -a ldap/[Intra-array DNS Name] [NETBIOS Name]
setspn -a ldap/[Intra-array DNS Name] :2171 [NETBIOS Name]
setspn –a ldap/TMG01-IA.DOMAIN.COM TMG01
setspn –a ldap/TMG01-IA.DOMAIN.COM:2171 TMG01
To check the SPNs are correctly configured, use “setspn –L [NETBIOS Name]”
This needs to be configured on each array member.
On TMG01 - In the Threat Management Gateway console, under Firewall Policy > Toolbox (on the right hand pane), expand Computer Sets and add TMG01 and TMG02 to the groups “Managed Server Computers” and “Remote Management Computers”
On TMG02 – open the Threat Management Console, select the server and select “Join Array” from the Tasks tab
Select the option to join a stand-alone array
Enter the IP address for TMG01 on the intra-array network as the array manager, since this is a domain environment use the credentials of the logged on user
Finish the wizard
The wizard will then copy the configurations from the designated Array Manager, this takes short while and will probably disconnect your session if managing remotely.
Back on TMG01, open the System pane and look at the Servers tab – hit refresh if you can’t see the second server. You should see TMG01 and TMG02, with TMG01 reporting as the Array Manager and TMG02 reporting as the Array Managed. It may take a while for the egg timer to turn to a green tick for the managed server.
Right click each server in turn and select properties, then select the Communication tab. Under Intra-Array Communication and select the IP address on the intra-array network.
From the Roles Configuration page, open the “Configure Array Properties” and change the DNS Name to the intra-array DNS name configured earlier
It may take a while, but the array will sort itself out
You can also check the synchronisation status under the monitoring tab
Under the Firewall Policy tab, go to the Toolbox and expand the Protocols pane. Launch the New Protocol Definition Wizard
Create new protocol as follows (some places recommend port 10000-11000 but the firewall logs show connection attempts up to port 14000)
Click through the rest of the wizard, keeping defaults and apply the configuration change
Switch to the Tasks tab and click “Create Access Rule”
The rule is to allow traffic
On the new customised Protocol
From Local host and the Intra-Array Communications network
To the same destinations
Apply the new rule to all users, finish the wizard and apply to the server – wait for the array to converge again before moving on
From the networking tab, click the “Enable Network Load Balancing Integration”
Enable load balancing for the internal and perimeter networks
For each network configure the Virtual IP address and Cluster mode by clicking “Configure NLB Settings…”
The Primary VIP for the internal network is the IP we registered earlier for proxy.mdlimited.com (192.168.8.30). The external VIP is the next IP address in the DMZ. If the Cluster Operation Mode is set to Unicast mode the vSwitch on the server must be configured as per the VMware recommendations for NLB configuration – it must accept forged MAC addresses and must not send updates to the physical switch
It takes a few minutes for the configurations to converge and for the NLB to come online, check the Configuration tab under Monitoring, and look at the Services tab to see that the NLB service is running in both servers
At this point the forward proxy NLB should be operational so you can change your browser to point to proxy.domain.com and test it.
To finish up the external NLB setup, you simply map the public IP address on your front firewall to the DMZ NLB IP address. You can then use any of the publishing wizards to publish OWA, HTTP or other internal services. If you need additional IP addresses, remember to use the NLB properties in the TMG console to add a new VIP rather than the NLB MMC.
Since this post has well exceeded 2000 words, I’m going to leave it there – I hope this has been informative, please leave feedback!