If you would like to read the other parts in this article series please go to:
If you would like to read the other parts in this article series please go to:
Test Lab Exercise
If you are new to the Forefront Edge scene, or maybe just have not been paying attention to my blog, you might not know that the chairs on the deck of Forefront edge security have changed. In the past, we have gotten accustomed to seeing the ISA firewall as the preferred edge security solution and we have used it as a remote access VPN server, site to site VPN gateway, reverse Web proxy and secure server publishing solution. Because of the ISA firewall’s superior application layer inspection and granular user/group based access controls, the ISA firewall was the preferred solution for remote access.
That was then. With the upcoming releases of the Threat Management Gateway RTM (I will call it RTM to contrast it with the TMG MBE that comes with EBS, which is essentially ISA 2006 R2 for 64 bit computing) and the Unified Access Gateway (UAG, the next version of IAG), TMG will be seen, primarily, as an outbound access Unified Threat Management (UTM) solution and UAG will be the preferred solution for inbound access.
That is not to say that the inbound access capabilities included in ISA have been removed from TMG. They will all be included with TMG, but I do not think you will see any major investments in inbound access with TMG RTM and future versions. There is nothing new for inbound reverse proxy, there is nothing new when it comes to server publishing and there is nothing particular exciting when it comes to site to site VPNs (although it is sort of a stretch to think of site to site VPN as being inbound access).
For exciting new inbound access features, you need to look at the upcoming UAG. The next version of IAG will include enhanced reverse Web proxy capabilities and sport advanced application layer inspection for a number of Microsoft and non-Microsoft Web applications. UAG will continue to have the Network Connector for network level SSL VPN, but it will also support other VPN protocols such as; PPTP, L2TP/IPsec and the new SSTP VPN protocol, which was initially introduced with Windows Server 2008 and Vista SP1. Probably the most exciting inbound access/remote access feature to be included with UAG is comprehensive support for DirectAccess, including enhanced NLB capabilities and DNS64 and NAT64 so that even if your current network infrastructure is not completely IPv6 enabled, you will be able to get up and running quickly with DirectAccess.
While the UAG will be the preferred solution for remote access/inbound access, this does not mean that you can not use the TMG firewall as your inbound access solution. UAG will likely be targeted as large mid-sized businesses and enterprises, and the pricing is going to be consistent with that targeting. Because of the hefty price tag that is going to pinned on the UAG, the TMG firewall is probably going to remain very popular among small to smaller mid-sized businesses. If you are in the small to small-midsized markets, then you will be interested in anything that the upcoming TMG firewall is going to have to offer.
The good news is that while not a lot of investments were made for inbound access control and technology, with the upcoming TMG firewall, there is one very bright light worth paying attention to and getting to know about. That bright light comes in the form of full support for remote access VPN connectivity using SSTP. With SSTP added to the TMG firewall’s VPN toolset, you will have the choice of PPTP, L2TP/IPsec or SSTP for remote access VPN client connections.
Why Use the Secure Socket Tunneling Protocol (SSTP)?
Why introduce a new VPN protocol? PPTP and L2TP/IPsec have been with us a long time and have for the most part served us very well. Both protocols have worked with Windows RRAS and ISA firewall’s for the last decade and we have become accustomed to using them. We know how to set them up, users know how to create connectoids or use the connectoids we provide them in CMAK packages, and we know the support issues and have playbooks for just about all the VPN support scenarios.
Given all that experience with PPTP and L2TP/IPsec, it should be clear on why we do need a new VPN protocol. How many times have your users been stuck in a hotel or conference center or coffee shop or somewhere else where all they could get outbound was HTTP and HTTPS? Or maybe you have found yourself in the same boat. What did you do? If the problem was email access, most of us just fell back on OWA. If network access was required, then life got a lot more difficult, and sometimes there was no option other than changing location or hotel and hope that you could get a better connection. That is expensive, time consuming and generally an outrageous hassle.
That’s why SSTP is such a gift for the TMG firewall admin. SSTP, which is the Secure Socket Tunnel Protocol, tunnels PPP connections over an SSL encrypted HTTP connection. Because the application layer transport is HTTP, it can be tunneled over firewalls that only allow TCP ports 80 and 443 outbound, or when only an outbound Web proxy is the only option for Internet access. Yes, SSTP will work through Web proxies. However, the Web proxy device in front of the SSTP VPN client must not require authentication, as there is no way to configure the SSTP VPN client to send credentials to the Web proxy server.
SSTP does have a few modest requirements:
SSTP only works with Vista SP1 and above client operating systems (this includes Vista SP2 and Windows 7)
Windows Server 2008 and Windows Server 2008 R2 can also act as SSTP VPN clients
SSTP is not available for site to site VPN connections
SSTP VPN servers, including the TMG firewall, require a Web site certificate to bind to the SSTP Web Listener
The SSTP VPN client must be able to check the Certificate Revocation List (CRL) to confirm that the Web site certificate bound to the SSTP Web Listener hasn’t been revoked (CRL checking can be disabled on the client, but that’s not a good idea for a production deployment)
The TMG firewall also needs to be able to check the CRL for the Web site certificate used by the SSTP Web Listener. There is a System Policy Rule that will allow this. Whether this is enabled by default by the time TMG goes RTM isn’t sure at this time, so it’s something you might want to check at that time
Only Windows Server 2008 and Windows Server 2008 R2 can act as SSTP VPN servers. That would not be a problem for the TMG RTM firewall admin, since TMG RTM will only run on Windows Server 2008 or Windows Server 2008 R2 64 bit
An important consideration for the TMG firewall admin is that when you configure the firewall to accept SSTP connections, you actually create a Web Listener to accept the connections. This Web Listener is configured to allow anonymous connections. You will need to dedicate an IP address for the Web Listener, since this is an SSL connection with a certificate bound to this listener. If you want to publish any other SSL sites using the same TMG firewall, you will need additional IP addresses to support those connections. You would not be able to use the same Web Listener is you want to configure the firewall to pre-authenticate published Web servers. Given that almost all published SSL sites should be protected with pre-authentication, you will need more than one IP address on the external interface of the TMG firewall if you want to support both SSTP and pre-authenticated SSL Web Publishing Rules.
What About VPN Reconnect?
The TMG firewall will support three VPN protocols supported by Windows Server 2008 and Windows Server 2008 R2 RRAS:
It might be more accurate to say that TMG provides integrated support for these three VPN protocols, meaning that connections using these protocols and configured in the TMG firewall console will be exposed to stateful packet and application layer inspection and firewall policy rules can be created to enable strong source/destination/user/group based access controls. VPN client connections will be as secure as any other connection moving to or through the firewall.
In Windows Server 2008, RRAS will support another VPN protocol, called VPN Reconnect. VPN Reconnect uses IPsec tunnel-mode with Internet Key Exchange version 2 (IKEv2), which is described in RFC 4306, specifically taking advantage of the IKEv2 mobility and multi-homing extension (MOBIKE) described in RFC 4555.
VPN Reconnect is actually a very cool and useful VPN protocol. While all of us would like to deploy DirectAccess as soon as possible, there are a number of IPv6 potholes in the path of DirectAccess that might turn your DirectAccess dreams into networking nightmares, and sour you on the entire DirectAccess promise. If you are not ready for DirectAccess, do not sweat it. There is time to bring your network or your IPv6 knowledge up to requirements. Until then, take advantage of VPN Reconnect. It gives you some of nice transparency that DirectAccess provides, but doesn’t stub its toe on IPv6 complexities.
VPN Reconnect was designed to make life easier for people who use WWAN connections, sometimes referred to as “air cards” or “wireless broadband”. Imagine that you are using a WWAN connection on a train or subway. You have VPN’d into the corporate network happily doing email, connecting to intranet sites and doing all the other stuff you do when connected to the corpnet over VPN. Then bam! You enter a tunnel and the VPN connection is dropped. Sure, the VPN connectoid is configured to automatically redial the connection, but you see the dialog box and you see the countdown timer and you might see this happen several times as the reconnection attempts proceed.
With VPN reconnect, the system sees the connection as “interrupted” but not disconnected. So that when you get out of the tunnel, data begins to flow again, but the system never sees the connection as dropped. This provides a much more pleasant and integrated computing experience compared to PPTP, L2TP/IPsec and SSTP remote access VPN connections.
VPN Reconnect is implemented in the RRAS role service of the Network Policy and Access Services (NPAS) role of a computer running Windows Server 2008 R2. Infrastructure considerations include those for NPAS and RRAS. Client computers must be running Windows 7 to take advantage of VPN Reconnect.
However, the TMG firewall does not include integrated support for VPN Reconnect. That is not to say that you ca not use it with the TMG firewall, but you are not going to get the same level of security you will with the integrated VPN protocols. I will write more about VPN Reconnect in a future article either here on ISAserver.org or on www.windowsnetworking.com.
How Does SSTP Work?
The SSTP connection process is fairly straightforward. The following shows how the SSTP connection process works:
- The SSTP VPN client establishes a TCP connection with the SSTP VPN gateway between a random TCP source port on the SSTP VPN client and TCP port 443 on the SSTP VPN gateway.
- The SSTP VPN client sends an SSL Client-Hello message, indicating that the SSTP VPN client wants to establish an SSL session with the SSTP VPN gateway.
- The SSTP VPN gateway sends its computer certificate to the SSTP VPN client.
- The SSTP VPN client validates the computer certificate by checking its Trusted Root Certification Authorities certificates store to see if the CA certificate that signed the server certificate is located in that store. The SSTP VPN client then determines the encryption method for the SSL session, generates an SSL session key and encrypts it with the SSTP VPN gateway’s public key, and then sends the encrypted form of the SSL session key to the SSTP VPN gateway.
- The SSTP VPN gateway decrypts the encrypted SSL session key with the private key of its computer certificate’s private key. All future communication between the SSTP VPN client and the SSTP VPN gateway is encrypted with the negotiated encryption method and SSL session key.
- The SSTP VPN client sends an HTTP over SSL (HTTPS) request message to the SSTP VPN gateway.
- The SSTP VPN client negotiates an SSTP tunnel with the SSTP VPN gateway.
- The SSTP VPN client negotiates a PPP connection with the SSTP server. This negotiation includes authenticating the user’s credentials using standard PPP authentication methods (or even EAP authentication) and configuring settings for Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) traffic.
- The SSTP client begins sending IPv4 or IPv6 traffic over the PPP link.
For those of you who are interested in the characteristics of the VPN protocol architecture, you can see that in the figure below. Notice that SSTP has an additional header compared to the other two VPN protocols. That because there is HTTPS encapsulation in addition to the SSTP header. L2TP and PPTP do not have application layer headers encapsulating the communication.
The Lab Environment
As the title of this article indicates, this series is about setting up TMG Beta 3 in a test lab. That means I am getting to learn about it as we go along, so you can see the mistakes that I made, what questions I have that are unanswered, and the general trial and error you see with any TMG firewall admin who likes to try and make things work before reading the manual. Of course, I will read the manual when things do not work, and I will make a note when reading the manual did not help, or even when it made things worse!
The lab environment is pretty simple. There are only three computers, as you can see in the figure below.
The domain controller is a Windows Server 2003 virtual machine acting as a DC, DHCP server, DNS server, and certificate server. You might ask why I used Windows Server 2003 instead of Windows Server 2008. The answer is that I already had the Windows Server 2003 virtual machine available and I did not want to take the time to put together a Windows Server 2008 domain controller. Everything will work with Windows Server 2008 and Windows Server 2008 R2, so if you want to use those OSs for your DC, go for it. I am using VMware Workstation 6.5.x and the domain controller is on VMNet2.
The TMG firewall virtual machine has two NICs. The internal interface is on VMNet2 and the external interface is on a bridged network adapter and has a valid IP address on the live network. TMG beta 3 is running on Windows Server 2008 64 bit edition and was fully updated before installing the TMG software. The TMG installation process is vastly improved over the ISA setup routines, but I am not going to go over that in this article series. I will show you the TMG installation experience in a future article.
The external SSTP client is a Window 7 virtual machine and it has a single bridged network adapter and has a valid IP address on the live network. This VPN client is a workgroup member is not a member of the internal domain. I chose this scenario because domain member machines are more likely going to be using DirectAccess than SSTP, so I used what I consider the “forward thinking” scenario here.
That is it. Next time we will go over the configuration processes. We will start with creating the certificate used by the SSTP Web Listener, then, we will import that certificate into the TMG firewall’s machine certificate store. We will then publish the CRL site and talk a little bit about CRL issues. We will then configure the SSTP VPN settings and finally, finish up with the client side settings and establish the VPN connection to see if it actually works. See you then! –Tom.
If you would like to read the other parts in this article series please go to:
- Configuring TMG Beta 3 for SSTP VPN Connections – Part 2: Configuring the Firewall to Accept SSTP Connections
- Configuring TMG Beta 3 for SSTP VPN Connections – Part 3: Configure TMG VPN Settings and Making the Connection