Considerations for the TMG Firewall in Supporting Services (Part 6)

If you would like to read the other parts in this article series please go to:


In the first articles in this series, I went over a number of issues that involve domain membership for TMG firewalls, and then looked at authentication issues for both outbound connections and inbound connections to Windows machines. In the last article in the series, we talked about some of the special authentication issues for non-Windows clients. I hope that you found those articles useful.

However, today as I was thinking about that series and reviewing everything that I covered, I realized that there is yet another collection of authentication considerations that I left out. What I neglected to talk about was the TMG firewall’s robust VPN capabilities and the authentication issues that come up in regard to those capabilities.

You all know that I have long held that the TMG firewall was one of the most secure and configurable VPN series on the market, at least it was when TMG was actually on the market. Although you can longer buy the TMG firewall (so it’s technically not “on the market”), there’s no reason that you can’t keep on using it for a while. Microsoft is going to continue to support the TMG firewall until the year 2020, so that gives you six more years to take advantage of its features and functionality and get the most out of the money you spent for it over that time period.

Some IT pros have told me that they even want to run it after Microsoft ceases to support it, although I can’t see how it could be a good idea to run a firewall that doesn’t get security updates. You also have to take into consideration that the operating system on which it runs won’t be supported by the time the TMG firewall support runs out. Thus, I think that six-year time frame is about all you should plan on, unless something truly drastic happens and Microsoft either decides to “reimagine” TMG and bring it back or sell the technology to some other company that can take it into the future. Much as I’d like to see one of those happen, I’m not counting on it.

Configuring authentication options for the TMG VPN server

As you probably already know, most of the TMG firewall VPN configuration comes from the RRAS component of the Windows Server operating system on which TMG is running. However, the TMG firewall adds a lot to the server’s core RRAS capabilities and makes it a lot easier to configure the VPN server component. While there aren’t a large number of authentication options available with the VPN server component of the TMG firewall, there are a few that are worth knowing about. Let’s take a look at those now.

To get to the VPN server authentication configuration, click on the Remote Access Policy node in the left pane of the TMG firewall console. When you click that node, you’ll see that there are several VPN configuration options. One of the interesting (and potentially confusing) things about the options in the right pane of the console is that several of the links there will take you to the same dialog box. The only difference is that when you click on a particular option, a different tab in that dialog box will be displayed. Now that we understand how the navigation works, let’s click on the Select Authentication Methods link in the right pane of the console.

Figure 1

After you click on the Select Authentication Methods link in the right pane of the console, you’ll see something similar to what you see in Figure 2 below.

Figure 2

As you can see in the figure, this takes you to the options in the Remote Access Policy (VPN) Properties dialog box and the Authentication tab will be open for you to peruse.

On the authentication tab, you have the following options, which are going to look very familiar to any Windows IT professional:

  • Microsoft encrypted authentication version 2 (MS_CHAPv2)
  • Extensible authentication protocol (EAP) with smart card or other certificate
  • Encrypted authentication (CHAP). Requires reversible passwords
  • Unencrypted password (PAP)
  • Allow customer IPsec policy for L2TP connection

Selecting the best authentication option

The best authentication option for your purposes will depend on your particular users, equipment and security level needs.


Selecting the first option will cause the TMG firewall to require the remote access VPN client to use the MS_CHAPv2 protocol to authenticate to the TMG firewall. Of course, this is a remote access authentication protocol that is standard with all Windows VPN clients. It is also the default protocol that’s used by the TMG firewall. It’s easy to use and I would consider this to be a reasonably secure option for authentication with the TMG firewall’s remote access VPN server.

EAP with smart card or other certificate

The next option is the Extensible authentication protocol (EA) with smart card or other certificate authentication option. This is the most secure authentication option for authenticating to the TMG firewall. However, this is also the most complex configuration option for authenticating to the TMG firewall’s VPN server component, and it can also be the most expensive, if you need to buy smart cards and card reader equipment. When you enable this option, the TMG firewall can be configured to require the VPN client to present a certificate to the VPN server in order to authenticate. The certificate needs to be trusted by the TMG firewall.

This option also allows you to configure the TMG firewall to accept a smart card, on which there is stored a certificate that can be presented to the TMG firewall. This provides the advantages of multi-factor authentication since the user must provide “something they have” (the physical card) in addition to “something they know.”

In addition, this option allows you to configure the TMG firewall to enforce Network Access Protection (NAP) policies so that VPN clients will be put onto a quarantine network before being allowed access to the corporate network. VPN clients will have to be able to prove that they are configured in a way dictated by your policy before they are allowed onto the corporate network. While this is a very secure and powerful option, the configuration of the NAP solution is somewhat complex. However, if you want to make your remote access VPN solution as secure as possible, it’s worth your time to master the configuration of TMG VPN integrated NAP to give you the best possible security solution.


There are two more authentication protocols that you should know about that are supported by the TMG VPN server. However, keep in mind that you should only use these protocols if you have clients that are running Windows NT 4.0 or Windows 98. I know some companies are slow about upgrading but I doubt that any of you are still using Windows NT 4.0 or Windows 98. If any of you are running those operating systems out there, let me know! It would be very interesting to hear from folks who are running such ancient operating systems and if you are, whether or not they are also acting as VPN clients. That would be really interesting (although a security nightmare that I don’t even want to think about).

At any rate, the authentication protocols that are used by these very old client operating systems are supported in the options Encrypted authentication (CHAP). Requires reversible passwords and unencrypted password (PAP). Now, these are very unsecure password authentication mechanisms and my official advice is that you should never use them. If you have a very low security environment and have no other choice, I suppose they’re better than nothing but don’t be surprised if you find that passwords have been stolen and that strange things end up happening.

Customer IPsec policy for L2TP connection

The last option you see in this dialog box is the one to Allow customer IPsec policy for L2TP connection. This is one of the best features of the TMG firewall for hurried and hassled administrators. In the past, the ISA firewall did support L2TP/IPsec remote access VPN client connections and that was great. What wasn’t so great was that you had to deploy a Public Key Infrastructure (PKI) to make it work. The reason for that was that, in order to use an L2TP/IPsec connection, you had to deploy certificates to both the VPN client and the TMG VPN server. Then the client and server would perform mutual authentication and complete the IPsec negotiation process. While this was very secure, it was a bit of a pain to set up. Unfortunately, given that pain, many ISA firewall administrators decided to avoid it by using PPTP instead of IPsec. That was a big problem from a security standpoint, because PPTP is not secure and should be avoided for today’s VPN connections. The attraction of PPTP, though, was that it was essentially “set it and forget it.”

The solution to the complexity problem came about when the TMG firewall enabled pre-shared keys to remote access VPN client connections. Now all you have to do is configure the TMG firewall with a pre-shared key, and then configure the VPN clients to use the same pre-shared key, and it just works, just like with the PPTP VPN connections. That’s not so bad, and it’s more secure. But there’s always a catch, isn’t there? The problem with pre-shared keys is that they don’t scale very well. If you need to change the pre-shared key, you have to make sure that the pre-shared key is changed on all the VPN clients. I suppose you could use the CMAK to do this, though, so maybe the scalability issue isn’t that much of a problem.


The final authentication option is to use a RADIUS server. You can see the authentication options for RADIUS on the RADIUS tab, as shown in the figure below.

Figure 3

Just put a checkmark in the Use RADIUS for authentication checkbox and there you go! When you do that, you can then click the RADIUS Servers button to choose a RADIUS server that will be used to authenticate your remote users. One thing to be aware of is that if you enable RADIUS authentication, you are probably going to want to enable user mapping. User mapping can be used to map RADIUS authenticated VPN clients to the Windows namespace so that the access rules that are applied to Windows users and groups will be applied to RADIUS users. User mapping is configured in the VPN clients’ properties dialog box.


In this “bonus” article, we finished up our series on authentication issues with the TMG firewall by talking about the remote access VPN server authentication options. I hope you learned a thing or two in this article series and I look forward to working with you again when we tackle a whole new subject. Thanks! –Deb.

If you would like to read the other parts in this article series please go to:

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