TMG VPN: The Cloud Alternative (Part 2)

If you would like to read the first part in this article series please go to TMG VPN: The Cloud Alternative (Part 1).


In Part 1 of this article, we discussed the why and how of TMG VPN as an alternative to the cloud, for those situations where because of security and data governance or other issues, your organization has made the decision to keep some or all of its resources on premises.

You might have decided that there are some very key scenarios where going to the cloud is going to work just right for you. However, in the process, you’ve probably also discovered that the cloud isn’t a panacea, and there are quite a few twists and turns along the way. For this reason, you might have also decided that there will still be a number of core assets that you’re going to keep on premises.

The problem is that employees are going to need access to those resources and with the work force becoming more and more mobile, it’s highly likely that they’ll be needing access when they’re outside your corporate firewall. In your final analysis, you’ve determined that remote access VPN is the most secure solution.

But there are many different types of VPN, and it’s important to select the one(s) that will be right for your company’s personnel, data and needs. Today, then, we’ll talk about VPN protocols.

VPN Protocols

Before you can start to deploy your TMG VPN solution, you have to determine which VPN protocols you want the TMG firewall to support. TMG supports a number of different VPN protocols, but not all protocols are created equal, and some work better than others for specific scenarios. You’ll need to understand the protocols in order to determine which ones are the best fit for your tasks, so this might require a little research and study.

The TMG firewall supports a number of VPN protocols. These include:

  • PPTP
  • L2TP/IPsec
  • SSTP
  • IPsec IKEv2
  • IPsec tunnel mode

PPTP is the grandfather of VPN protocols. It has been around since the Windows NT days and it is considered to be pretty long in the tooth. A number of security problems have been associated with PPTP and therefore it is no longer considered a secure VPN protocol. There is a way to make PPTP more secure, by using certificate mapping and RADIUS, but the administrative overhead for such a solution isn’t consistent with modern network management practices. While PPTP is easy to configure and maintain, it’s pretty much been relegated to home users who want a quick and easy way to VPN into their home networks. PPTP has no place on a 21st century enterprise network.

L2TP/IPsec was designed to be the secure replacement for PPTP. Built through a cooperative effort between Microsoft and Cisco, L2TP/IPsec used IPsec as the encryption mechanism for securing the VPN channel. L2TP was used instead of GRE (which is used by PPTP) as the virtual layer 2 tunneling protocol. In its early incarnations, L2TP/IPsec was somewhat difficult to configure because of the hard-coded certificate requirements. After Microsoft updated its IPsec stack, support was added for pre-shared keys. For a number of years, pre-shared keys were considered to be less secure than certificate based alternatives. In addition, enterprise management of pre-shared keys was seen as not being scalable. One does have to wonder what the Microsoft position is now on pre-shared keys, as we see them used in several places on Microsoft Azure. However, in the places that they are used, they are not being used in a strictly enterprise context.

With pre-shared key support, Microsoft most enterprise IT organizations considered L2TP/IPsec to be a serviceable VPN protocol. That serviceability was also enhanced by NAT Traversal (NAT-T) support. NAT-T enabled you to put the VPN server or VPN client behind a NAT device. This was especially helpful for site to site VPN connections, where most organizations did not want to put the ISA or TMG firewall on the edge of the network, but instead put the ISA or TMG firewall behind a corporate NAT device. NAT-T was extremely popular and continues to be somewhat of a sticking point for mid-sized and even some small enterprise organizations, who would like to create site to site VPNs connecting their on-premises datacenters to Microsoft Azure, but are unable to do so due to the lack of NAT-T support. However, as is the case with all things cloud, and especially with the fast-paced advances of the Microsoft Azure cloud, it might just be a matter of time before NAT-T is supported. Or maybe it will never be supported. I don’t know, and if I did know, I couldn’t tell you.

The problem with L2TP/IPsec is that it isn’t the most firewall friendly VPN protocol. While it is friendlier in a certain respect than PPTP (which required a NAT editor to support GRE), you still have to allow “non-standard” (i.e., not TCP ports 80 and 443) protocols through the corporate firewall. This led to many meetings with the network security guys who acted in the role of “Dr. No” – as in no, we will not “open” those ports for you.

Given the popularity of the “SSL VPN” concept in the mid-2000’s, Microsoft realized that they were climbing uphill by pushing L2TP/IPsec as the secure VPN protocol of choice. To solve the problem with the network security group, and bring the VPN protocol within the fold of standard protocols, Microsoft decided that they would encapsulate and tunnel the VPN traffic over a TLS-secured HTTP tunnel. HTTP would be the transport (in a loose sense of the term “transport”, not the technical meaning of transport, as in a “transport protocol”, such as TCP or UDP) for this new protocol. This would make it firewall and proxy server friendly (although not entirely proxy friendly, as you would subsequently have to go through some contortions to make it work through a proxy connection). This new remote access VPN client protocol would be the Secure Socket Tunneling Protocol or SSTP.

SSTP is available on all Windows client systems beginning with Vista. It’s also available on Windows Server systems beginning with Windows Server 2008. The nice thing about SSTP is that it combines the ease of configuration that L2TP had with pre-shared keys, and the simplicity of the firewall configuration, which only requires that you allow TCP 443 inbound and outbound (outbound from the client side and inbound from the TMG firewall side).

At this time, SSTP is the VPN protocol of choice for Microsoft client systems. While there is no Microsoft led effort to create an SSTP client for Linux or Mac, there are third party solution that enable these client operating systems to connect to the TMG firewall SSTP VPN server. SSTP remote access VPN connections are also used when connecting to an Azure Virtual Network for a VPN connection. The term that Microsoft Azure uses for this is “point to site” which might confuse experienced networking people. Point-to-site VPN connections are nothing more and nothing less than a remote access VPN connection over SSTP.

The encryption protocol used by SSTP is IPsec, so you don’t need to worry about the security issues that you might encounter with older protocols. There is support for both certificate based authentication and pre-shared keys. Most enterprise deployments will prefer a PKI based solution over a pre-shared key solution.

Another VPN protocol that you don’t hear as much about is IKEv2, also known as “VPN Reconnect” and a handful of other terms.

IKEv2/VPN Reconnect uses IPsec tunnel mode to allow remote access VPN client connections without the overhead of using L2TP or HTTP as a “transport” for the tunnel. One of the nice things about VPN Reconnect is that if the connection is dropped for some kind of network connectivity reasons, it will be automatically reestablished when connectivity is restored. And in Windows 8 and above, you can configure specific applications that need corporate network access to automatically trigger VPN connect to establish a VPN connection without user intervention.

The final VPN option available to you isn’t a remote access VPN client connection. Instead of connecting a single client system to your network, you connect entire networks to one another. This is the site to site VPN option. The TMG firewall supports site to site VPN connections using all of its available protocols except for SSTP. There is no such thing (at least for now) as a site to site SSTP VPN connection. If you want to use the TMG firewall for site to site VPN connectivity, you’ll have to use PPTP, L2TP/IPsec or IPsec tunnel mode.

IPsec tunnel mode is the last of our five choices when it comes to VPN protocols. In Windows, you can use IPsec in either tunnel mode or transport mode. Transport mode is used when the VPN client is establishing a point to point link with another IPsec enabled device, such as a server that requires IPsec authentication and encryption before allowing access to its contents from over the network. In contrast, IPsec tunnel mode is used to create a secure tunnel between IPsec VPN gateways. These gateways act as virtual network routers and represent the endpoints for the site to site VPN connection.

The TMG firewall supports IPsec tunnel mode site to site VPN connections. The primary reason for adding this support is that IPsec tunnel mode has become the de facto site to site VPN protocol, and so the TMG firewall needed to support this protocol so that it could connect to Cisco VPN concentrators and other popular vendor’s VPN gateways.


The TMG firewall supports a number of protocols that you can use for remote access VPN client connections as well as site to site VPN connections. The preferred protocol for general use in a remote access VPN client connection scenario is SSTP, and for site to site VPNs, the preferred protocol is IPsec tunnel mode. So there you have it. We hope this gets you started in your quest to use TMG VPN as a viable alternative to cloud computing.

If you would like to read the first part in this article series please go to TMG VPN: The Cloud Alternative (Part 1).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top