If you would like to read the other parts in this article please go to:
- Considerations for Replacing your TMG Firewall (Part 1)
- Considerations for Replacing your TMG Firewall (Part 2)
- Considerations for Replacing your TMG Firewall (Part 4)
- Considerations for Replacing your TMG Firewall (Part 5)
In part one of this article, I began the discussion about what you might
want to think about when you are evaluating new firewalls to replace your TMG firewall. There are literally thousands of features that you might want to consider and we don’t want to go through each and every one of those. Instead, what we’re trying to do here is look at what the key and important features are in the TMG firewall and call them out, and discuss their capabilities, so that you can be able to more clearly determine whether those capabilities are available with the other firewalls on your candidates list.
In the second part of this series, we talked about a key capability that’s included in the TMG firewall that is hard to find in any of the competing solutions; that was the ability to pre-authenticate and pre-authorize connections to published web sites through the TMG firewall. I suspect that will be the feature that you’re going to find is the most difficult to replicate in a replacement for the TMG firewall. While there may be features in future versions of Windows that could replace these capabilities, that isn’t something that we can count on at this point in time, so you’ll need to think about this when looking for your next firewall or web proxy server.
As a reminder, here is the list of TMG firewall capabilities we started with the first week of this series:
- Inbound SSL Bridging
- Outbound SSL Bridging – SSL inspection
- Pre-authenticating and delegating Web Proxy
- SSTP VPN Server – remote access client VPN server
- Site to Site VPN server
- Winsock Proxy
- URL Filtering
- Web Antimalware
- Multi-ISP connectivity
- Network Load Balancing – HA support
This week, we’ll take a look at what some people might call the more mundane features of the TMG firewall. These are the remote access VPN and site to site VPN gateway abilities that are used to provide secure access to your network for remote client computers.
Remote Access VPN Server
Windows NT provided me with my first in-depth experience with VPN servers. I can remember reading about VPN technology back in the 90s and how I thought it would be really cool to be able to create a virtual Ethernet connection between a computer that was connected to the Internet somewhere “out there” in the world and my NT Server based VPN server at home. It seemed incredible at the time to think that, when I was traveling, I could still get to all my files that were stored on my file servers and workstations at home. Of course, that was almost two decades ago and VPN servers don’t seem nearly as magical now as they did then. Nonetheless, VPN servers are the bread and butter of many remote access solutions for many organizations today, and if you use the TMG firewall for your VPN server, you’ll want to make sure that the replacement for the TMG firewall offers VPN services that will have most or all of the key capabilities that you’re using today.
So, what are those key features of the TMG VPN server that you’ll want to look for in potential replacements? Of course, that’s going to depend on your own particular needs and usage scenarios. Some of the ones that I think are most important include the following:
- SSTP – a firewall friendly, firewall traversal VPN protocol
- L2TP/IPsec – a secure VPN protocol that uses IPsec to secure the connection
- PPTP – a no brainer protocol that allows you to get a VPN client server connection up and running in almost no time
- EAP/TLS – an extension to the authentication and authorization capabilities of the VPN server so that you can use things such as certificate authentication and two-factor authentication
SSTP is relatively new, with support for it having been added to the TMG firewall after SSTP was introduced with Windows Server 2008. It wasn’t available in the ISA firewall; It was introduced as Microsoft’s answer to the spate of SSL VPN solutions that had started to come onto the market. The SSTP protocol encapsulates the PPP header in a TLS HTTP header so that it can traverse port restricted firewalls and web proxy devices. That capability makes it very handy and it works with all modern Windows clients running Vista and above. SSTP isn’t too difficult to set up, although it does require at least a basic PKI to support the server authentication requirement. When looking for a new firewall, you should consider one that offers a similar firewall traversal protocol. It doesn’t have to be SSTP, but SSTP is convenient to use because its client side software comes with your Windows clients.
Of course, not everyone is running Vista and above, and there’s a good chance you might have some non-Windows clients that need to connect through a VPN, too. In that case, you won’t be able to use SSTP for them, although you might be able to use some other firewall friendly VPN protocol. But if not, almost all clients support L2TP/IPsec. This protocol came about through a joint effort of Microsoft and Cisco, and in spite of the fact that Cisco gave up on it in favor of IPsec transport mode, it’s still a very popular VPN protocol. It’s secured by IPsec, so the credentials are not passed in the clear. While best practices dictate that you should use a PKI for client/server authentication, L2TP/IPsec does support pre-shared keys as well. Many administrators use those to get up and running, and a surprising number of organizations continue to use them in production, although that is definitely not recommended in high security environments.
Almost any new firewall that you might be considering is going to support L2TP/IPsec, so that shouldn’t be much of a problem as you consider migration to a new network security platform.
PPTP and EAP/TLS
PPTP is another VPN protocol that is supported by the TMG firewall. While it’s been standard since those early NT VPN servers, I don’t know if I’d make PPTP support a requirement for any new firewall that I was considering. The reason for that is that there have been long running concerns over the security of the PPTP protocol. And in the last year, some of those concerns were elevated by even more sophisticated attacks, to the point where Microsoft now considers the PPTP protocol completely deprecated and recommends that you not use it unless you take special measures to secure the credentials process.
So how do you secure the credentials exchange if you do want to use PPTP? That brings up the EAP/TLS discussion. EAP stands for the “Extended Authentication Protocol” and provides “extensions” that you can use to secure the credentials exchange process. As you can guess from the name of the protocol, the Transport Layer Security protocol is used to encrypt the credentials exchange process. You can use EAP/TLS to enable certificate based authentication, and you can even use two-factor authentication methods that enable you to use PPTP as your VPN protocol.
The problem with this is that the most common reason that people like to use PPTP is because it’s a no-brainer to set up. There aren’t any certificate requirements or special configuration needs on the client or server. All you have to do is run the VPN wizard on the TMG firewall and it just works. However, that “just works” aspect of PPTP goes away when you introduce EAP/TLS because the TLS requires that there be some kind of PKI in place. Ouch.
One problem with PPTP is that it’s not very firewall friendly. The reason for that is in order for PPTP to work across NAT devices, the NAT device (such as a firewall) must have a PPTP editor. As many of you who have worked with PPTP in the past, not all NAT editors are created equal. This has led to many difficult to troubleshoot issues for ISA and TMG firewall administrators when their clients were located behind firewalls with buggy PPTP NAT editors.
However, if you do want to keep using PPTP, there is a nice article on the ISAserver.org site that will show you how to do that. Check out the article here.
Site to Site VPN Server
A site to site VPN server allows you to connect entire networks to each other. They are essentially VPN routers. They route connections from one network over another network using a VPN connection between the site to site VPN servers over the Internet. The site to site VPN capability enables you to save money because you don’t need to use expensive dedicated WAN links to connect your networks.
Site to site VPN servers are typically used to connect the “main office” to branch offices and Windows and TMG make pretty good site to site VPN server solutions in most cases. There are some significant limitations to the TMG offering, though, since it doesn’t support dynamic routing protocols. This is something that you might want to look for in your next firewall that supports site to site VPN.
In addition, if you really want a full features IPsec tunnel mode connection, TMG is probably not the best solution because of the complex routing issues that are involved with IPsec configuration in TMG and Windows. In contrast to the intuitive routing configuration that was surfaced in the RRAS console for PPTP and L2TP/IPsec VPN connections, the IPsec tunnel mode configuration was described by one TMG admin I know as “like walking through mud with blinders on.” Even worse, troubleshooting these IPsec connections require a great deal of expertise, and this expertise was very hard to find.
So when you’re considering your next firewall, I’d advise you to check out the IPsec tunnel mode support and consider how easy it is to configure the routing for it. IPsec tunnel mode is essentially the de factor site to site VPN protocol these days, so you’re going to want to make sure your next solution has robust support for it.
In Part 3 of this article, we continued our series on the things you should consider when evaluating potential replacements for the TMG firewall. We talked about the remote access VPN server features and protocol support and the characteristics of those protocols that should be included in your replacement device or software. We also talked a bit about site to site VPN servers and the factors you should consider when looking for a site to site VPN replacement. We’ll continue down the list next time a discuss more of the features you need to consider. See you then! –Deb.
If you would like to read the other parts in this article please go to: