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 1: Overview of VPN Configuration
- Checking Out the TMG 2010 Virtual Private Network Server - Part 3: Configuring the TMG Firewall as a L2TP/IPsec Remote Access VPN Server
In the previous article in this series, Overview of VPN Configuration, I provided an overview of the TMG firewall’s remote access VPN configuration interface. We discussed the controls that are available and where they are located. Now we will find out how to configure the firewall to accept PPTP and L2TP/IPsec connections.
The PPTP Remote Access VPN Server
PPTP was the first remote access VPN protocol used by the Microsoft remote access VPN server. PPTP got a bit of a bad reputation early on when a security issue was identified, which made the protocol vulnerable to a password based attack. That issue was resolved with the release of PPTPv2, but PPTP still is thought by most security experts to be a less than optimal VPN protocol. This is due to the fact that authentication takes place outside of a secure encrypted tunnel context.
Now, if you use complex passwords or use EAP/TLS user certificate based authentication for your PPTP connections, the security issues are less problematic than some would lead you to believe. In fact, unless you’re in a high security industry, or an industry where enemy governments or well-funded competitors with supercomputers are “out to get you”, PPTP can be a reasonable choice for a remote access VPN protocol.
PPTP is popular among ISA and TMG firewall admins because “it just works”. However, I should say that “it just works” might be too much of a stretch. What I can say is that PPTP “works out of the box”. I can’t say that “it just works” because there are times when PPTP does not work, such as when the PPTP client or PPTP server is located behind a NAT device that doesn’t contain a PPTP NAT editor or that has a buggy NAT editor.
And that is worth bringing up because PPTP, like most other VPN protocols, is not what you would call “firewall friendly.” This hooks into the entire subject of why we should look toward future methods of remote access, such as DirectAccess, instead of relying on the traditional VPN. However, because DirectAccess is available only to Windows 7 clients and has a number of other requirements that might lock many of your client computers out of the DirectAccess solution, remote access VPN remains a viable and sometimes necessary option.
You should be aware that many third party firewalls have buggy PPTP NAT editors, so that only a single outbound PPTP connection can be made from behind the firewall. Or in other cases, the NAT editor is so faulty that no clients are able to establish a connection from behind the firewall with the faulty PPTP NAT editor. You can always hope that you will find yourself located behind an RRAS NAT server or an ISA or TMG firewall, but sometimes you are just not that lucky. In those cases, you can try to use another remote access VPN protocol or some other method of remote access to get to the information you need.
If you remember the items we covered in the last article, you’ll recall that we configured the VPN server to use DHCP to obtain IP addresses for the remote access VPN clients. We also enabled the default VPN protocol configuration, which is PPTP. The TMG firewall was listening on the default external interface for remote access VPN client connections and using the default authentication method, MS-CHAPv2. That’s all we did – and most of what we did used the default settings, so we didn’t even have to do much in terms of configuration.
Now let’s take it a step further. I have a Windows 7 client that I’ll connect to a network that’s external to the TMG firewall and then I will attempt a VPN connection. I am going to assume that you already know how to create a VPN connectoid on a Windows 7 client, so I will not go through that process.
If you don’t know how to do that, just open the Network and Sharing Center and click the Set up a new connection or network link and follow the wizard.
Before I connect, I would like to show you something in the VPN client configuration that will help you with troubleshooting various VPN protocols. In Figure 1 below, you can see the Properties dialog box for the VPN client connectoid. When you click the Security tab, the Type of VPN drop-down box appears. When you open that list, you will see a list of VPN protocols that the remote access VPN client supports. In this example, we want to force the VPN client to use PPTP. Select that option and then make the connection.
After making the connection, you can right click the VPN connectoid in the Network Connections window and click Status. In the Status dialog box, click the Details tab and there you will see details of the PPTP connection. You can see that the WAN Miniport (PPTP) protocol is used, the authentication method and IP addressing information, as shown in Figure 2.
In the TMG firewall console, in the Dashboard, you can see the connection in the Sessions section as shown in Figure 3.
When you move to the Monitoring node in the left pane of the TMG firewall console and click the Sessions tab, you can see the VPN client connection. If you have a busy remote access VPN server, you can use the filtering feature that is part of the Sessions tab and configure the filter to show only the remote access VPN client connections. Notice that this node also provides information regarding the VPN protocol that is used to connect to the TMG firewall’s remote access VPN server as well as the user name of the connected user. This is shown in Figure 4.
That was pretty easy, wasn’t it? Now you know why admins like configuring ISA and TMG as PPTP remote access VPN servers. Sure, you could get fancy and enable EAP/TLS authentication, use a RADIUS server, and do a few more things to extend your PPTP VPN server’s security and access control configuration – but if you just want a quick and easy solution, PPTP is the way to go (at least from the server side of the configuration).
But wait a minute – all we have done so far is configure the TMG firewall to be a remote access VPN server and verify that a PPTP connection could be established. What we haven’t done yet is connect to any resources on the internal network to make sure that the connection actually works.
An easy way to test this is to see if we can ping a domain controller on the internal network. The IP address of the domain controller is 10.0.0.2. Figure 5 below shows the results of that ping.
Uh oh. What’s up with that? What’s up with that is that the TMG firewall requires more than just a VPN connection. Remember, the TMG firewall is a brick when you take it out of the box. By default, no traffic can move through the firewall. You have to create rules to allow traffic to pass through the firewall.
Okay, then. Let’s create that rule.
In the left pane of the TMG firewall console, click the Firewall Policy node. In the right pane of the console, click the Tasks Tab. In the Tasks Tab, click the Create Access Rule link, as shown in Figure 6.
On the Welcome to the New Access Rule Wizard dialog box, shown in Figure 7, enter a name for the rule in the Access Rule name text box. In this example, we’ll name the rule VPN Clients to Internal and then click Next.
On the Rule Action page, shown in Figure 8, select the Allow option, since we want to use this rule to allow traffic from the VPN Clients Network to the default Internal Network. Click Next.
On the Protocols page, shown in Figure 9, you can select which protocols are to be allowed from the source to the destination Network (or computer or other network object). In this example, we’ll allow all traffic from the VPN Clients Network to the default Internal Network, so we’ll select the All outbound traffic option from the This rule applies to drop down list. Click Next.
On the Malware Inspection page, shown in Figure 10, we will select the Do not enable malware inspection for this rule option. The reason we are choosing this option is a matter of convenience in this example. Note that in a production environment, you would want to allow the VPN clients to be protected from malware, since split tunneling is disabled by default. Because split tunneling is disabled, the VPN clients will have to access the Internet through a resource you make available on your corpnet. That resource could be another TMG firewall or web proxy, or it can be the TMG firewall that the VPN client is connecting to in order to establish the remote access VPN client session.
In this example, we’re not going to create a rule to allow Internet access while connected to the VPN – your own policies will determine if you want to allow Internet access while the VPN client is connected, and whether you want to allow split tunneling when the VPN client is connected to the TMG remote access VPN server.
On the Access Rule Source page, click the Add button and click the Networks node. Then double click the VPN Clients Network and click Close in the Add Network Entities dialog box, as shown in Figure 11. Click Next.
In the Access Rule Destination page, click the Add button. In the Add Network Entities dialog box shown in Figure 12, click the Networks node and then double click the Internal Network. Click Close in the Add Network Entities dialog box. Click Next.
On the User Sets page, shown in Figure 13, use the default entry, which is All Users. Note that in a production environment, you might want to limit which users can connect through this rule, or create other rules that apply to remote access VPN clients. Be aware that when a computer connects over the remote access VPN connection, the TMG firewall has the user context of the session. This is a good thing – because the VPN clients are like Firewall Clients (TMG Clients) in that the user context is available for connections made through the TMG firewall and that enables you to create rules based on users and groups to allow VPN clients connectivity to resources behind the TMG firewall.
On the Completing the New Access Rule Wizard page, shown in Figure 14, click Finish.
Now in the middle pane of the TMG firewall console, you’ll see the new rule. Click the Apply button, which you can see in Figure 15, to save the changes to firewall policy.
Now let’s test this configuration, using a ping to the domain controller on the corpnet. Hurray! It worked this time because the rule allowed the connection, as you can see in Figure 16.
What else can we do? Since we allowed all protocols, we should be able to connect to an SMB share or at least see a list of them on the domain controller. Yep, that works, too, as you can see in Figure 17.
All right. We’re moving right along now. Next, let’s take a look at the TMG filewall’s log files, shown in Figure 18, and find out what happened. You can see in the details section of the ping attempt that the rule VPN Clients to Internal allowed the ping to the destination 10.0.0.2. What’s interesting is that the user context is included, which isn’t what you might expect from non-firewall clients. But as I mentioned earlier, when a user connects as a remote access VPN client, you have the user information available to the firewall, and it can be used in Firewall rules. Note that while we get the user information as we do with the Firewall (TMG) client, we don’t get support for complex protocols as we do with the Firewall (TMG) client.
In this article, we took a look at a simple PPTP remote access VPN connection. We configured the PPTP VPN server, and then we created an Access Rule that allowed connectivity between the VPN client and resources on the default Internal Network. But PPTP is just the beginning. I thought we would start with the easy stuff and then move on to more difficult configurations, so in the next article we will find out how to deploy the L2TP/IPsec VPN server.
This is going to be a bit more complicated, because we will need to deploy certificates to both the VPN client (the CA certificate) and the TMG firewall (a server certificate). This can get a bit tricky, because the utility of the web enrollment site has changed with Windows Server 2008 R2, and that means we can not leverage that tool to get the web site certificate easily. In addition, there is an issue with the RPC filter (if you know about this issue in previous versions of the firewall, yes, it is still there). This makes using the certificates MMC problematic. But we will address those issues and provide potential solutions in the next article. See you then! – Deb.
If you would like to read the other parts in this article series please go to