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

If you would like to read the first part in this article series please go to The TMG Firewall’s VPN Server and Site to Site VPN Gateway Capabilities (Part 1).

User Mapping of VPN Clients

User mapping is a feature that allows you to map virtual private network (VPN) clients connecting to ISA Server to the Windows namespace by using an authentication method that is not based on “Windows authentication” (such as RADIUS or EAP authentication). With user mapping enabled and configured, firewall policy access rules specifying user sets for Windows users and groups are also applied to authenticated users who do not use Windows authentication. So why do you want to do this? Default firewall policy access rules will not be applied to users from namespaces that are not based on Windows, unless you define user mapping for users. Thus the user mapping feature extends the strong user/group-based access controls that can be applied to VPN clients who use an authentication method other than Windows.

This is important because Windows authentication of domain users is only available when the TMG firewall belongs to the domain that contains the users’ accounts, or to a domain that is trusted by the user accounts’ domain. If the TMG firewall does not belong to a domain, then Windows authentication is used only for those user accounts that are stored on the TMG firewall machine itself.

With user mapping, you can use RADIUS authentication of domain users, and you can apply user/group-based access control over VPN clients who authenticate via RADIUS. Without user mapping, you would not have access to strong user/group-based access control, and Access Policies from the VPN Clients Network to the Internal network would be limited to controlling protocol and server access to all users connecting to the VPN.

SecureNAT Client Support for VPN Connections

When a VPN client connects to the VPN server, the routing table on the VPN client changes so that the default gateway becomes the IP address of the VPN server. This causes a potential problem for VPN clients, in that while they are connected to the VPN, they cannot access resources on the Internet at the same time.

Once upon a time, there was a problem with the ISA Server 2000 firewall/VPN servers so that, for VPN clients to access resources on the Internet, you had to choose from one of the three following options:

  • Enabling split tunneling on the VPN client

  • Installing the Firewall Client software on the VPN client machines

  • Configuring the Dial-up and Virtual Private Network settings of the VPN connection with Proxy Server settings (this enables browsing with Internet Explorer only when the client is connected to the VPN).

Split tunneling refers to a configuration wherein the VPN client machine is not configured to use the default gateway on the remote network. The default setting for Microsoft VPN clients is to use the default gateway for the remote network. Remember that a VPN requires two connections: first, a connection is made to the Internet (with broadband or other always-on technology, this connection does not have to be manually established each time); second, the VPN connection is established over the Internet connection. When VPN clients are configured not to use the default gateway, they can access resources on the corporate network through the VPN connection, and they can also access resources on the Internet via the Internet connection that was established by the VPN client machine before the VPN connection took place.

The problem with that is that there are some serious security threats that occur when the VPN client machine can access the Internet directly and at the same time is able to access the corporate network via the VPN link. This allows the VPN client computer to completely bypass all Internet access policies that were configured on the ISA Server 2000 firewall for the duration of the VPN connection. The effect of split tunneling is similar to allowing users on the corporate network to have local modem connections along with their connections to the LAN. The modem connections would completely bypass the ISA Server 2000 firewall policy and allow the workstation to have access to the Internet that would not otherwise be allowed by the ISA Server 2000 firewall policies. This creates a potential for downloading worms, viruses, and other dangerous content. A malicious user on the Internet would even be able to route exploits from an outside computer through the machine that is performing split tunneling and into the corporate network.

Because of this risk, it was important to provide an alternate method of allowing VPN clients Internet access while connected to the TMG firewall/VPN server. The preferred alternative with ISA 2000 is to install the firewall client software on the VPN client machine. The Firewall Client will forward requests directly to the ISA Server firewall’s internal IP address and does not require split tunneling to allow the client computer to connect to the Internet. In addition, the Firewall Client exposes the VPN client machine to the ISA Server 2000 firewall access policies.

The TMG firewall/VPN servers solve the problem of split tunneling without requiring installation of the Firewall client by enabling Internet access for VPN SecureNAT clients. The VPN clients are SecureNAT clients of the TMG firewall by default, because they use the firewall as their default gateway. The TMG firewall/VPN server can use the log-on credentials of the VPN client to apply strong user- and group-based access controls in order to limit the sites, content, and protocols that the VPN client machines will be allowed to access on the Internet.

Tip:
Even though the Firewall client software is not required on VPN client computers to allow them to access the Internet through the TMG firewall machine, you might still want to install the Firewall client on VPN client machines if you want to support complex protocols that require one or more secondary connections. SecureNAT clients can’t use complex protocols that require secondary connections unless there is an application filter to support the secondary connections. Firewall client machines can access any TCP or UDP protocol, even those that require secondary connections, without the requirement of the Application Filter.

An alternative to using the Firewall client on the VPN client is to configure the Dial-up and Network settings of the VPN client connection object in Internet Explorer with Proxy Server settings. If you are using ISA Server 2000, you can configure the VPN connection object with the same Web Proxy settings that are used by internal clients. However, this approach allows VPN clients to use HTTP, HTTP(S) and FTP (download only) protocols for Internet access. This same feature is available when connecting to TMG firewall/VPN servers.

Site-to-Site VPN Using IPSec Tunnel Mode

TMG firewalls enable you to use IPSec tunnel mode for site-to-site links between a TMG VPN gateway and a third-party VPN gateway. You can still use PPTP or high security L2TP/IPSec to create site-to-site links between two TMG firewall/VPN gateways, but TMG enables you to use a lower security IPSec tunnel mode connection to connect to third party VPN gateways.

Note:
IPSec tunnel mode is supported only for site-to-site VPN connections. Client-to-server remote-access VPN connections still use only PPTP or L2TP/IPSec. When using IPSec tunnel mode, you should be aware that it is vulnerable to several well-known exploits, whereas L2TP/IPSec requires stronger authentication and is not as vulnerable to these attacks. Thus, when you have a choice, L2TP/IPSec is the preferred VPN protocol set for site-to-site VPN connections.

Publishing PPTP VPN Servers

In some previous versions of the ISA firewall, Server Publishing Rules limited you to publishing servers that required only TCP or UDP protocols. In other words, you could not publish servers that required non-TCP or UDP protocols, such as ICMP or GRE. This meant you could not publish a PPTP server because it uses the GRE protocol, which is a non-TCP or UDP protocol. The only alternative with ISA Server 2000 was to put these servers on a perimeter network segment and use packet filters to allow the required protocols to and from the Internet.

The TMG firewall has solves this problem. You can create Server Publishing Rules for any IP protocol. This includes Server Publishing Rules for GRE. The TMG firewall’s enhanced PPTP filter now allows inbound and outbound access. The new inbound access support means you can publish a PPTP VPN server located behind a TMG firewall.

Pre-shared Key Support for IPSec VPN Connections

A Public Key Infrastructure (PKI) is necessary in high-security environments so that computer and user certificates can be issued to the computers that participate in an IPSec-based VPN connection. Digital certificates are used for computer authentication for L2TP/IPSec remote access and gateway-to-gateway connections, and for IPSec tunnel mode connections. Certificates can also be used for user authentication for both PPTP and L2TP/IPSec connections.

Setting up a PKI is not a simple task, and many network administrators do not have the time or the expertise to implement one quickly. In that case, there is another way to benefit from the level of security provided by IPSec-protected VPN connections.

With the TMG firewall, you can use pre-shared keys instead of certificates when you create remote access and gateway-to-gateway VPN connections. All VPN client machines running the updated L2TP/IPSec VPN client software can use a pre-shared key to create an L2TP/IPSec remote-access VPN client connection with the TMG firewall/VPN server.

Warning:
Pre-shared keys for IPSec-based VPN connections should be used with caution. Certificates are still the preferred method.

Be aware that a single remote-access server can use only one pre-shared key for all L2TP/IPSec connections that require a pre-shared key for authentication. You must issue the same pre-shared key to all L2TP/IPSec VPN clients connecting to the remote-access server using a pre-shared key. Unless you distribute the pre-shared key within a Connection Manager profile (CMAK), each user will have to manually enter the preshared key into the VPN client software settings. This reduces the security of the L2TP/IPSec VPN deployment and increases the probability of user error and an increased number of support calls related to L2TP/IPSec connection failures.

Warning:
If the pre-shared key on the TMG firewall/VPN server is changed, a client with a manually configured pre-shared key will not be able to connect using the L2TP/IPSec pre-shared key until the key on the client machine is also changed.

Despite its security drawbacks, the ability to easily use pre-shared keys to create secure L2TP/IPSec connections to the TMG firewall/VPN server is popular among some firewall administrators. Pre-shared keys are an ideal “stop gap” measure that you can put into place immediately and use while in the process of putting together a certificate-based Public Key Infrastructure. When the PKI is complete, you can then migrate the clients from pre-shared keys to high-security computer and user certificate authentication.

Monitoring of VPN Client Connections

You can use the real-time log viewer to look at ongoing VPN remote-access client connections and filter it to view only VPN client connections. If you log to a database, you can query the database to view an historical record of VPN connections. With the TMG firewall/VPN servers, you can not only get complete information about who connected to the TMG firewall/VPN, but you also get information about what resources those users connected to and what protocols they used to connect to those resources.

For example, you can filter VPN criteria in the log viewer if you are using live logging and are logging to a file. What you can’t do with file-based logging is use the ISA firewall’s log viewer to query the archived data. However, you can still filter and monitor real-time VPN connections in the log viewer. In addition, you can filter VPN connections in both the Sessions view and the Log view.

Summary

In this article, we finished up our discussion of some of the key features and capabilities included in the TMG firewall and VPN server and gateway. The TMG firewall is the ideal solution for both a remote access VPN server and a site to site VPN gateway. You can use the TMG firewall on both sides of a site to site VPN solution, or you can use the IPsec tunnel mode option to connect the TMG firewall to a third party VPN gateway. I hope you enjoyed this series and please let me know if you have any questions. Thanks! –Deb.

If you would like to read the first part in this article series please go to The TMG Firewall’s VPN Server and Site to Site VPN Gateway Capabilities (Part 1).

Leave a Comment

Your email address will not be published.

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

Scroll to Top