The TMG Firewall’s VPN Server and Site to Site VPN Gateway Capabilities (Part 1)

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our ISAserver.org Real Time Article newsletter.

Introduction

Virtual private networking (VPN) continuous to be popular and continues to be a standard for companies that have telecommuters, executives, and outside salespeople who need network access when on the road, and/or partners and customers who need access to resources on the corporate network from other locations. The purpose of VPN networking is to allow remote access to resources on the corporate network that would otherwise only be available if the user were directly connected to the corporate LAN. With a VPN connection, the user has a “virtual” point-to-point link between the remote VPN user and the corporate network. The user can work as if he/she were on site; applications and services running on the users’ computers treat the VPN link as if it were a typical Ethernet connection. The Internet over which the client is connected to the corporate network is completely transparent to the users and applications.

One of the major advantages of using a VPN connection instead of a client/server Web application is that VPN users at remote locations can potentially access all of the protocols and servers on the corporate network. This means your users can access the full range of services on Microsoft Exchange Servers, Microsoft SharePoint Servers, Microsoft SQL Servers, and Microsoft Lync Servers just as they do when they are directly connected to the network at the corporate location. VPN client software is built into all modern Windows operating systems. A Windows VPN user does not need to install any special software to connect to each of these services, and it’s not necessary to create special proxy applications to allow your users to connect to these resources.

VPN vs. DirectAccess

You might have heard that Microsoft’s DirectAccess technology will make VPNs obsolete. Certainly DirectAccess has some major advantages over the traditional VPN; it’s easy for users (because they don’t have to explicitly make the connection each time as they do with a VPN) and it gives admins more control, because they can remotely manage the client computers – even install updates and apply Group Policies – without the user even being logged on.

However, there are many reasons that some organizations won’t be able to deploy DirectAccess. First, it requires Windows Server 2008 R2; if your network is still running on Server 2003, DA isn’t an option. You also have to have Windows 7 or above clients, and you might still have clients running XP. Finally, to get full functionality from DA, you need to use the version that’s in Forefront UAG (or Windows Server 2012). UAG is expensive, and Server 2012 hasn’t been released yet and most companies won’t upgrade to it immediately.

The reports of the VPN’s death have been greatly exaggerated. Until your network infrastructure supports DA, the VPN is still the best option for connecting remote clients to your corporate network securely.

History of Microsoft Firewall VPN capabilities

ISA Server 2000 was the first Microsoft firewall to provide tightly integrated VPN configuration and management. ISA Server 2000 included easy-to-use wizards that made it simple to create remote access and site-to-site (gateway-to-gateway) VPN connections to the ISA Server 2000 firewall/VPN server. However, there were still some improvements that could be made. The ISA Server 2000 VPN server still required the firewall administrator to spend a significant amount of time fine-tuning the VPN server configuration via the Routing and Remote Access console.

ISA Server 2004 significantly enhanced the VPN components that are included with the Windows 2000 and Windows Server 2003 Routing and Remote Access Services (RRAS). The administrator can enable, configure, and manage the VPN server and gateway components directly from the ISA 2004 firewall management console, rather than having to go back and forth between the ISA MMC and the RRAS MMC. You rarely need to use the Routing and Remote Access console to configure VPN components. This firewall-centric approach to VPN configuration continues with the TMG firewall.

ISA Server 2006 had the same VPN features as its predecessor and added the Branch Office VPN Connectivity Wizard for configuring site-to-site VPN connections.

TMG was released in 2010 and added support for SSTP VPNs and improved Network Access Protection (NAP) for VPN clients.

TMG Today

Today’s TMG firewall with Service Pack 2 includes the following major features that provide a great VPN experience for both the admin and the user:

  • Firewall Policy Applied to VPN Client Connections
  • Firewall Policy Applied to VPN Site-to-Site Connections
  • VPN Quarantine
  • User Mapping of VPN Clients
  • SecureNAT Client Support for VPN Connections
  • Site-to-Site VPN using Tunnel Mode IPSec
  • Publishing PPTP VPN Servers
  • Pre-shared Key Support for IPSec VPN Connections
  • Advanced Name Server Assignment for VPN Clients
  • Monitoring of VPN Client Connections

These VPN server and gateway features make the TMG firewall one of the most powerful co-located VPN and firewall solutions on the market today. In the following sections, I’ll discuss these new features and how they work together to make the TMG firewall VPN solution the VPN of choice for all organizations running Microsoft networks.

Firewall Policy Applied to VPN Client Connections

When a VPN remote-access client establishes a connection with the VPN server, the VPN client acts as if it were a machine that is directly connected to the corporate network. This virtual link to the corporate network enables remote VPN users to access almost every resource on the corporate network, limited only by the access controls that are configured on the servers and workstations. However, you need to keep in mind that this power to access virtually any resource on the corporate network can pose a security risk. Generally, you should not allow users to have a full range of access to corporate resources when they connect over a remote access VPN connection. That’s because these users might be connecting from computers that aren’t within your control and don’t conform to corporate software and security policies, or they might be connecting from computers that are on untrusted networks, such as hotel broadband networks. You have no way of knowing whether these machines pose a threat to your network.

Your VPN policy should stipulate that only highly-trusted users who are connecting from known trusted machines on known trusted networks are allowed unfettered access to the corporate network over a remote-access VPN link. Examples of users who might be granted such access include your network, security, and firewall administrators, and perhaps some highly-placed executives. All other users should be restricted to accessing only the subset of network resources that they need to do their jobs when connected via the VPN link.

For example, many firewall administrators allow users to connect over VPN so that they can use the full Outlook MAPI client to access a Microsoft Exchange Server. Microsoft Exchange provides several different methods for remotely accessing Exchange Server resources. These include the SMTP, POP3, IMAP3, and Outlook Web Access (OWA) services. However, many users like to keep the broader range of options that are available to them when using the full Outlook MAPI client.

There are basically three ways to satisfy users’ needs in this situation:

  • Publish the Exchange Server using the TMG firewall’s secure RPC Server Publishing Rule
  • Have your users use the RPC over HTTP protocol
  • Grant your users VPN access to the corporate network

The TMG firewall secure RPC Server Publishing mechanism enables remote Outlook MAPI clients to connect to the full range of Microsoft Exchange Server services from any remote location. The only problem is that, for security reasons, many firewalls and ISPs have blocked access to the RPC port mapper port (TCP 135). This port is required to make the initial secure connection to the Exchange Server using a secure Exchange RPC publishing rule, but the Blaster worm, which exploited this port, caused most administrators to shut it down several years ago. Consequently, RPC publishing has lost much of its former utility. The good news is that a number of organizations are now starting to open up all ports, due to the realization that “port-based” access control is considered little more than “security theater” by many network security experts.

RPC over HTTPS can solve the problem by encapsulating the RPC connection inside an HTTP header. This allows the Outlook MAPI client to send requests to the Exchange Server using HTTP. HTTP is generally allowed by all corporate firewalls and ISPs, since it is used for Web communications. The problem with this solution is that not all organizations have fully enabled RPC/HTTPS because of lack of training or lack of time to learn how to configure it.

Granting users VPN access will circumvent the limitations of the other solutions, but as mentioned above, providing such access can pose a security risk when all VPN clients can access the entire network. So how do you manage users’ access levels? The ideal solution is to enforce Access Policy on VPN clients, based on user/group accounts. This way, users can access only the servers and protocols they require.

The good news is that the TMG firewall gives administrators this level of access control. When VPN clients connect to the VPN server, those clients are placed on a built-in network entity called the VPN Clients Network. The TMG firewall treats this network like any other network, which means strong user- and group-based access controls can be placed on data that travels between the VPN Clients Network and the corporate network.

All you need to do is create the user accounts and create a firewall rule on the TMG firewall/VPN server that limits what machines and protocols the users/groups can access and use, and all those network devices are protected from the VPN remote-access users.

This feature virtually eliminates the need for SSL VPNs (except in those circumstances where remote users are behind extremely restrictive firewalls that block all but HTTP and SSL connections outbound) and other proprietary remote-access solutions aimed at providing per protocol, per server, per user/group access to corporate network resources. Most commercial broadband networks at hotels and conference centers allow outbound PPTP and L2TP/IPSec via NAT Traversal. This way, you can provide remote access for your VPN users without the security threat that typically accompanies VPN client connections.

Firewall Policy Applied to VPN Site- to-Site Connections

A site-to-site VPN connection connects two or more networks (instead of an individual client and a network) over the Internet. Using a VPN site-to-site link can create substantial cost savings in comparison to dedicated WAN links that use dedicated circuits (for example, linking two sites via T-3 as once was the standard practice).

To use a VPN site-to-site link, each site must have a VPN gateway and a relatively inexpensive Internet connection. When the VPN gateways establish connections with one another, the site-to-site VPN link is established. Then the users on each end can communicate with other networks over the VPN site-to-site link just as they would with a routed connection on their own network. The VPN gateways act as routers and route the packets to the appropriate network.

VPN site-to-site connections use the same technologies as do client-to-server (remote access) VPN connections – and traditionally suffered from the same security problem. That is, all users had access to the entire network to which their own network was connected. The only thing that kept users out of network resources which they had no permission to access was local access controls on the servers.

Site-to-site VPN connections are typically set up between branch office and main office networks. So just as in the case of individual remote users, branch office users with access to the entire main office network can pose a major security threat.

The TMG firewall/VPN server can solve this problem by controlling outbound data that travels through the site-to-site link. Users at the branch office can be limited to only the resources on the main office network that they must have to do their jobs, and thus are prevented from accessing other computer resources on the main network. As with remote-access VPN clients, the users at the branch office should only be allowed to use the specific protocols they need on the servers they are allowed to access.

VPN site-to-site connections that take advantage of strong user- and group-based access controls can save money without sacrificing security.

Summary

In this article, we took a look at some of the features that make the TMG firewall the ideal VPN server and VPN site to site gateway solution for any Microsoft or hybrid network. In the Part 2 of this series, we’ll complete our discussion about this collection of features. See you then! –Deb.

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our ISAserver.org Real Time Article newsletter.

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