TMG VPN: The Cloud Alternative (Part 1)

If you would like to read the next part of this article series please go to TMG VPN: The Cloud Alternative (Part 2).


With all the talk of the cloud in the current IT environment (or at least among the IT journalists), you’d almost think that no company is storing any information on-premises anymore, or if they do, they are actively working to get all that data off their internal datacenters and into some cloud (preferably Microsoft Azure, or course). However, I suspect that, as with TV and movies and science fiction books, current reality is a bit different than what you see in the “news” and that whatever the future might bring, at present the overwhelming bulk of corporate information is still located on-premises.

Fear of the Cloud

There are many different reasons for this, with security being the primary issue. I don’t want to get into the issues of cloud security and data governance, but let’s just say that at this time, many corporate decision-makers don’t consider putting the company jewels into a shared cloud infrastructure to be the yellow brick road to success.

That’s not to say that this won’t change in the future, nor am I saying that it isn’t true that professional managed public clouds are likely more secure than your on-premises datacenter. But just as people used to be hesitant about putting a credit card number into a web site not that long ago, that’s the way many of them currently think in regard to putting proprietary information into a public cloud.

The “better safe than sorry” mentality prevails when any new way of doing things is in its early stages. Today, most of us have few qualms about online shopping, and indeed, recognize that some of the biggest data breaches of the past few years affected primarily customers using cards at bricks and mortar establishments. A similar change in sentiment will likely take place in the next ten years regarding cloud storage, but we aren’t quite there yet.

Meanwhile, back in the trenches

An important trend in the corporate world is the growing acceptance of remote workers. In spite of isolated CEO decisions at a few companies such as Yahoo, it has become pretty much universally accepted by the most forward thinking organizations that remote workers are the wave of the future and provide a significant competitive advantage to companies who use them versus those who don’t.

Of course, embracing a telecommuting work model can save a large company millions in reduce cost of office space and the attendant heating, cooling, parking, etc. that goes with it. But both organizations and their employees benefit. Many studies have suggested that remote workers tend to be more productive than those who are figuratively chained to on-premises corporate desk(top)s, that they work longer hours but have higher job satisfaction than on-premises employees.

A company that preferentially seeks out remote workers has a much larger pool of highly skilled people from which to choose – such companies are not self-limiting their searches to local talent or people who are willing to change locations. Companies that embrace remote work have unbound themselves from the chains of an industrial economy mindset and realize the advantages of a modern digital economy. Working remotely isn’t for everyone; some workers, especially at lower levels, lack the self-discipline required to work without constant direct supervision. Others simply need the social stimulation of in-person interactions throughout the work day. But many of the best and brightest do their best work outside of the constant interruptions of the typical office environment. The combination of higher productivity, access to the best talent available in the world, and the agility of digital econometrics makes companies who take advantage of this formidable foes for those stuck in the micromanagement mindset.

Securely integrating remote workers into the corporate network

Given that there is likely going to be an increasing number of remote workers now and in the future, and assuming that much of the information they will need to do their jobs will reside on local company networks for the near future, the immediate challenge is this: how do we allow those workers to securely gain access to information that remains within the confines of the corporate network?

You have a number of different options from which you can choose. Some of these include:

  • Remote access VPN client connections
  • Web access over HTTPS transports
  • Microsoft DirectAccess
  • Telnet
  • Remote Desktop Protocol

Each of these options is viable for some applications and some scenarios. Each of them has its own advantages and disadvantages. For example, Web access over the Internet to corporate resources using the HTTPS protocol is appropriate for web applications that you’re running on premises. That’s great for web applications, but what about applications that are not web enabled? (yes, there are many, many line of business applications that are not web enabled). For non-web enabled applications, access through a HTTPS transport isn’t going to work.

If you want to pick a method that pairs the attributes of support for the most applications with a high level of security, then remote access VPN client connections would probably be your method of choice. Of course, remote access VPN client connections aren’t necessarily the best in terms of deployment and operational overhead, but even then, if you do it correctly, it shouldn’t be too difficult to get even a large remote access VPN client connection infrastructure into place and keep it humming along nicely.

 The other potential downside with remote access VPN is the end-user. End-users are becoming increasingly dependent on not having to think about where data is located, so the idea of having to click on something to launch a VPN connection might be problematic to some modern users (who may not be nearly as sophisticated as the users you knew in the past).

With all that said, there is a lot to recommend remote access VPN client connections for access to corporate network resources.

Advantages of remote access VPN

Key attributes of these types of connections include:

  • A “virtual” connection to the corporate network, with a valid IP address assigned to the VPN client, so that it acts like a machine that is actually connected to the corporate network.
  • Full access to all types of applications, including web and non-web based applications.
  • Strong methods of authentication, including multi-factor authentication, so that only users who can successfully authenticate using strong authentication are allowed onto the corporate network over the VPN connection.
  • Strong methods of machine access control – methods can be put into place that qualify the machine connecting over the VPN connection to confirm that the machine has a security configuration that meets corporate requirements before the machine is allowed access to the network.
  • Universal connectivity from almost any location in the world – modern VPN protocols such as SSTP make it possible to use an HTTPS/SSL transport to carrier the VPN protocol packets over the Internet. Such protocols make it possible to create VPN connections through “restrictive” firewalls and web proxy servers.

Some of you might be thinking that there are other, better alternatives, such as something like Microsoft DirectAccess. I do agree that DirectAccess is a much more elegant solution, but it’s very complex to deploy and manage, and therefore might not be everyone’s preferred method of remote access. So let’s stick with VPN for now, and talk about some planning considerations for deploying remote access VPN for your remote workers.

Planning issues for a TMG-based VPN server

If you’ve decided that VPN is the most viable solution for your organization, the next question you’re likely to ask is: what should you use as your VPN server? There are tons of VPN servers from which you can choose, but if you have TMG, why not use your TMG firewall as a VPN server, or create a dedicated TMG firewall array to VPN duties? If you do this, you could dump your expensive “hardware” firewall and use a flexible and high performance TMG VPN server. If that sounds good to you, then read on.

The first step is to think about planning issues for the TMG based VPN server. The TMG firewall VPN server is a very flexible one and provides you with a myriad of options. You can use some of them or you can use all of them – you might feel like a kid in a candy store when you’re using the TMG firewall as a VPN server!

Things that you’ll need to consider when you plan and design for a TMG firewall VPN server solution include:

  • VPN protocols: which VPN protocols do you want the TMG firewall to support? 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 task, so this might require a little research and study.
  • Machine security validation: do you want to know that the machine that’s connecting to the TMG firewall VPN server is secure? If so, then you’ll need to understand how the TMG firewall can help you determine the security state of the machine that’s connecting to the TMG firewall VPN server and what your options are in this realm.
  • VPN authentication methods and protocols: The TMG firewall supports a wide array of VPN authentication methods and protocols. Some are used for very specific scenarios and some apply more widely. You’ll need to understand these protocols and methods before executing on a design exercise for your VPN server solution.
  • Application access control for VPN clients: do you want VPN clients to have the rule of the roost and be able to access any and everything located on the corporate network using any protocol? Or, would you prefer to constrain access to a specific set of resources? Going further, would you like to control based on users or groups and specify what a particular user or group can access on the corporate network over the VPN connection? If so, you’ll need to plan for these and understand how the TMG firewall makes this possible.
  • Certificate management: with all the security that’s involved with VPN connections, you just knew that there was going to be a ton of PKI involved, didn’t you? Well, there might be, depending on which types of VPN protocols and authentication methods you want to use. You’ll need to understand the PKI requirements for the VPN solution that you’ll ultimately design and then determine which of those are within the purview and skillsets of your organization.

With all this as background, we’ll be ready for the second part of this article series on planning for a remote access VPN client connection solution. The first step will be considering the different VPN protocols that are supported by the TMG firewall. We’ll talk about how those protocols work, what relative performance and reliable characteristics are, and in what scenarios you would want to use one or all of them. See you then! –Deb.

If you would like to read the next part of this article series please go to TMG VPN: The Cloud Alternative (Part 2).

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