If you would like to read the other parts in this article series please go to
- Checking Out the TMG 2010 Virtual Private Network Server – Part 2: Configuring the TMG Firewall as a PPTP Remote Access VPN Server
- Checking Out the TMG 2010 Virtual Private Network Server – Part 3: Configuring the TMG Firewall as a L2TP/IPsec Remote Access VPN Server
Introduction
Over the years, the ISA and later the TMG VPN server has been my best friend whenever I hit the road. With the introduction of ISA 2004, I knew that Microsoft had a real hit when it came to their VPN server. The ISA VPN server was a powerful remote access VPN solution that was exceptionally easy to configure. What I liked most about it was that after reviewing a number of VPN solutions over time, I’ve found the ISA VPN server to be one of the most secure on the market. And when it comes to remote access, security is everything.
I have to admit, though, that once my DirectAccess configuration got up and running, I have not been using VPN that much. However, there are times when I need to use a computer that isn’t DirectAccess capable, so I still depend on having VPN access to my network. That’s why I have a TMG VPN server running in the office.
In this series on the TMG VPN server, I am going to start with a general overview of the VPN configuration, and then move into the specifics of enabling L2TP/IPsec and SSTP access. If you are new to ISA/TMG, this will lay the foundation for what is coming up. If you are an experienced ISA VPN server admin, there is probably not much you will learn in this first article. However, you might want to check out the SSTP article in this series. I know that Tom did an article on SSTP with the beta version of the TMG firewall, but I hope to include a tip or trick or two that we have learned since then, that Tom did not include in his coverage of SSTP. So, if you’re an ISA VPN Pro, you can safely skip this first article. However, there is nothing wrong with a refresher if you want to continue reading – especially if it has been a while since you set up your ISA VPN.
Let us get started. Open the TMG firewall console and click on the Remote Access Policy (VPN) node in the left pane of the console. In the right pane of the console, in the VPN Clients Tasks list, click the Enable VPN Client Access link, as seen in the figure below.
Figure 1
Whoops! If you are an experienced ISA VPN admin who stayed with us, you will recognize this dialog box. It says that a Static address pool is the selected address assignment method for VPN access, but there are not enough IP addresses available for the VPN connection. To enable VPN access, you must first configure the address assignment method. Hmm… I don’t remember selecting a static address pool. In fact, I didn’t. However, the default setting is to use a static address pool and that’s why this dialog box appears. Click OK in this dialog box and let’s fix the problem.
Figure 2
In the right pane of the console, click the Define Address Assignments link, as seen in the figure below.
Figure 3
In the Remote Access Policy (VPN) Properties dialog box, click the Address Assignment tab. Select the Dynamic Host Configuration Protocol (DHCP) option. This configures the TMG firewall to obtain IP addresses for VPN clients (and its own RAS adapter) from a DHCP server. Note that only IP addresses are obtained from the VPN server. You won’t get DHCP options. In order to deliver DHCP options to the VPN clients, you will need to configure the TMG VPN server as a DHCP relay. We’ll talk about out how to do that on another day.
Notice the Use the following network to obtain DHCP, DNS and WINS services drop down list. This list contains the names of the NICs that are installed on the TMG firewall. The TMG firewall will use the DNS and WINS settings on the NIC you select to provide these services to the VPN clients. However, if you want to customize the configuration, you can click the Advanced button.
Figure 4
This brings up the Name Resolution dialog box. The default setting is Obtain DNS server addresses using DHCP configuration. However, you can choose the Use the following DNS server addresses and Use the following WINS server addresses options to apply addresses that aren’t part of the configuration on any of the NICs on the TMG firewall.
Figure 5
Click OK and then click Apply on the top of the middle pane to apply the changes to the Firewall Policy.
Now that the addressing issue is handled, click the Enable VPN Client Access link in the right pane of the console.
Figure 6
Click Apply at the top of the middle pane to save the changes to the Firewall Policy.
As mentioned previously, the TMG firewall obtains the IP addresses from the DHCP server. Here is how it works: The TMG firewall does not get these addresses one at a time. Instead, it requests the IP addresses in groups of ten. Of course, you need a DHCP server on your network for this to work. I have a DHCP server installed on the domain controller in the example network I’m using for this article. When you check the DHCP console, you will see that the TMG firewall has grabbed ten IP addresses from the DHCP server, as seen in the figure below.
Figure 7
Click the Configure VPN Client Access link in the right pane of the console.
Figure 8
In the VPN Clients Properties dialog box, on the General tab, you can see that the Enable VPN client access checkbox is enabled, and the Maximum number of VPN clients allowed is set to 100. With Standard Edition you’re limited to 1000 connections and with Enterprise Edition you have no limit (at least, you’re just limited to what your hardware and network will support).
Figure 9
Click the Groups tab. Here you can configure through Active Directory which user groups can connect to the VPN server. You select the groups by using the Add button. User accounts that belong to these domain groups should have VPN access configured in the account “dial-in” options set to control access via policy. This is the default for Windows Server 2008 domains, so I don’t need to do anything in Active Directory to make this work. If you’re using Windows Server 2003, you might want to check on those settings (I believe that if you use Windows Server 2003 Native you’ll be in good shape).
Figure 10
When you click the Add button, the Select Groups dialog box appears. For theFrom this location section, make sure that you have the domain selected. The default is the local computer, and you do not want to choose that. In this example, I have selected the msfirewall.org domain and will allow all users in the domain to connect to the VPN, so I entered Domain Users in the Enter the object names to select text box. Click OK to save the changes.
Figure 11
You can see the group appear in the list on the Groups tab now, as seen in the figure below.
Figure 12
Click the Protocols tab. Here you can choose which VPN protocols can be used to connect to the TMG VPN server. The options include:
- Enable PPTP
- Enable L2TP/IPsec
- Enable SSTP
The Enable PPTP option is enabled by default and will work without any additional configuration on the VPN clients and only minimal additional configuration on the TMG VPN server. However, if you select L2TP/IPsec or SSTP, you will need to deal with a number of issues related to certificates (well, you can use a pre-shared key with L2TP/IPsec, but that’s not very secure). We’ll go into the configuration requirements and procedures for these two VPN protocols later.
Figure 13
On the User Mapping tab, you are provided the option to map VPN clients from non-Windows namespaces (such as RADIUS or EAP authenticated users) to the Windows namespace. What this means is that if you do not use integrated authentication for VPN clients, and use RADIUS or EAP, you can not take advantage of the Windows Active Directory groups automatically. Thus, if user mapping is not enabled, you will have to create a user set on the TMG firewall and use that custom user set when configuring firewall rules that control access for VPN clients. Of course, in order for this to work, the TMG firewall must be a domain member. We will not use User Mapping in this example, since we won’t be using RADIUS or EAP authentication.
Figure 14
On the Quarantine tab, you can configure the TMG firewall to quarantine users before allowing access to the network if their computers do not meet security requirements. There are two ways you can do this: the first is to use remote access quarantine control and the second is to use NAP. In general, NAP is considered the better solution, but I have to admit that if you have the programming chops, or use a tool from Winfrasoft you have a lot more control with remote access quarantine control than you have with NAP, because the built-in NAP HSV isn’t very robust.
There are two primary choices here after you Enable Quarantine Control: Quarantine according to RADIUS server policies and Quarantine VPN clients according to TMG policies. The first is the NAP option and the second is the remote access quarantine control option. Note that you also have options to control how long to wait before you disconnect quarantined VPN clients and you can also configure a list of users who are exempt from quarantine control. We won’t go into the details of quarantine control in this article, but it’s worth going over the detailed configuration – so keep your eyes out for that in a future article.
Figure 15
Now let’s move to the General VPN Configuration section in the right pane of the console. Click the Select Access Networks link, as seen in the figure below.
Figure 16
On the Access Networks tab, select the Networks on which you want the VPN server to listen for connections. By default, the default External Network is selected. You can select any other Network, or any combination of Networks you like. Note that you can’t assign specific IP addresses; all IP addresses bound to NIC for the network you choose will listen for incoming connections. There is a way to specifywhich IP address is used, but I personally don’t see the point. If you’re allowing inbound connections for VPN users, it doesn’t matter which IP address is used. There are no real security advantages to limiting VPN access to a single IP address on the specified interface.
Figure 17
Click the Address Assignment tab. This should look familiar since we’ve been here before. If you decide that you want to use a static address pool, you can make that change here. An example of when you would want to change to a static address pool is when you want to configure an array of TMG VPN servers. In that case, each member of the array needs its own collection of IP addresses. We’ll go over how to configure TMG VPN server arrays in the future. In this example, we only have a single server.
Figure 18
On the Authentication tab, you can configure what type of user authentication you want to use. The default setting is MS-CHAPv2. You can also use EAP, CHAP and PAP, but in general the only options you’ll want to use are either MS-CHAPv2 or EAP. Notice that there is an option for computer authentication at the bottom. When you enable the Allow customer IPsec policy for L2TP checkbox, you can enter a pre-shared key. This is the “poor man’s” approach to IPsec security for L2TP/IPsec connections, as it allows you to establish the connection without deploying certificates. We’ll go over how to deploy the certificates in the next article in this series, so that you can use the recommended (and more secure) approach to L2TP/IPsec.
Figure 19
On the RADIUS tab, you can configure the RADIUS servers you want to use for VPN authentication or logging. Note that you can use RADIUS for either authentication or logging or for both. We will not be going into RADIUS server authentication or logging in this series.
Figure 20
Summary
Like ISA, the TMG firewall can act as a remote access VPN server. If you are an experienced ISA VPN server admin, you probably would not find much that’s new with the TMG VPN server configuration – with the exception of the SSTP integration. In the next article in this series, we will take a look at what you need to do to get L2TP/IPsec connections working, using computer certificates and pre-shared keys. We will also talk about firewall considerations that you have to take into account if you want to standardize on an L2TP/IPsec remote access VPN client configuration. See you then! –Deb.
If you would like to read the other parts in this article series please go to
