Checking Out the TMG 2010 Virtual Private Network Server - Part 2:
Configuring the TMG Firewall as a PPTP Remote Access VPN Server
by Deb Shinder [Published on 20 April 2010 / Last Updated on 20 May 2013]
1
How to configure the firewall to accept PPTP and L2TP/IPsec connections.
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
Introduction
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.
Advertisement
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.
NOTE:
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.
Figure 1
After making the connection, you can right click the VPN connectoid in the Network Connections window and clickStatus. 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.
Figure 2
In the TMG firewall console, in the Dashboard, you can see the connection in the Sessions section as shown in Figure 3.
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.
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.
Figure 5
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 theTasks Tab. In
the Tasks Tab, click the Create Access Rule link, as shown in Figure 6.
Figure 6
On the Welcome to the New Access Rule Wizard dialog box, shown in Figure 7, enter a name for the rule in theAccess Rule
name text box. In this example, we’ll name the rule VPN Clients to Internal and then click Next.
Figure 7
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.
Figure 8
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 todrop down list. Click Next.
Figure 9
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.
Figure 10
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.
Figure 11
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 Entitiesdialog box. Click Next.
Figure 12
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.
Click Next.
Figure 13
On the Completing the New Access Rule Wizard page, shown in Figure 14, click Finish.
Figure 14
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.
Figure 15
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.
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.
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 Internalallowed 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.
Figure 18
Summary
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.