We previously discussed PPTP VPNs, and supporting them with our TMG 2010 servers in this post, howto://configure pptp vpn support on tmg 2010. One of the things we pointed out there was that PPTP is an option for practically all clients. However, it does require holes in the firewall on the client’s side that aren’t always open. If you are supporting primarily Windows 7 clients, you really want to look at Microsoft’s version of an SSL VPN, the Secure Socket Tunneling Protocol.
Requiring Windows 7 or later on the client, and only needing only outbound TCP port 443 on the client’s side, the SSTP VPN allows full connectivity, just like any other VPN technology we might use. For those of us not saddled with legacy clients, this is the best VPN solution out there. If this sounds like your cuppa’ tea, read on.
Requirements for SSTP VPNs
It would be great if we could use SSTP VPNs for all of our clients, but currently they must be running Windows 7 or Windows 2008 or 2008 R2, and our VPN server must be running Windows 2008 or 2008 R2. Since we are talking about TMG servers, that server side bit should not be an issue. Those of you still supporting XP clients should look at this as another selling point on the upgrade path.
On the client’s network, the client must be able to make outbound connections on TCP port 443. Since the traffic requires only TCP 443 outbound (and of course, inbound on the server side) and looks like standard HTTPS traffic, practically any guest network, hotel, or hotspot can be used. If you can surf to secure websites, you can connect to the SSTP VPN.*
* Networks that use transparent tunneling of traffic through a proxy server may block this traffic if they do not recognise your root CA or cannot validate the certificate against the CRL. This alone is a strong argument for spending the money on a certificate from a public CA for this purpose.
On the server side, inbound TCP 443 traffic needs to be permitted to the TMG, and you may want to publish your CRL so that it can be checked from the outside if you are using internally generated certificates. Or, you can get around that part, as we’ll discuss below.
Setting it up on the TMG
The TMG Management Console divides this up into six sections, which makes for a pretty straightforward setup until you find that many of the steps take you to different tabs on the same dialog. We’re going to hit them the first time they pop up instead of running this strictly by the numbers. Browse down to Remote Access Policy (VPN), click it and then click on Configure Address Assignment Method to begin.
Step One-Configure Address Assignment Method
Click on the Configure Address Assignment Method, which brings up a new dialog that we begin on the second tab, which is kind of strange, but we can work with it. Here, since we are using a DHCP server on the internal network, we select the radio button for DHCP, and choose the Internal network from the drop down list for name resolution services.
If you want to set a static range, click that a radio button, select your server from the dropdown, enter your starting and ending address, and then click OK. Then clicked the Advanced button at the bottom of this tab to enter DNS and WINS server information.
Step Two-Access Networks
Click the Access Networks tab and make sure that both External and Internal networks are checked. That allows our VPN clients to connect from both our internal network (useful for testing) and the Internet.
Now click on the Authentication tab. To get PPTP up and running with the most secure password encryption, we’re going to only check MS-CHAPv2.
Since we are not going to use RADIUS in this post, click OK.
Step Four-Specify Windows Users
Click on Specify Windows Users and once again, land on the second tab of the dialog box. Here, you can add the AD group(s) that you want to permit to connect to your VPN. If that is everybody, select Domain Users.
Then click on the General tab, make sure the check box is set to Enable VPN client access, and enter the maximum number of concurrent connections you want to allow.
If you configured an all-purpose HTTPS listener like we covered in this post, you are all set. SSTP VPNs use a reserved URI in their request, so your TMG will recognise that request and connect to the VPN process instead of a published server.
Otherwise, create a listener for HTTPS that uses your certificate of choice, and does not require authentication. Select the appropriate external ip.addr and you are set.
At home, I use SSL certificates issued by my AD Integrated CA. That is because I am at home, and I can’t bring myself to drop a week’s worth of groceries on a certificate issued by a public CA. At work, and with clients, I always advocate using certificates from a public CA, and my CA of choice is Thawte. Using commercial certs ensures that trust issues don’t come up, and when dealing with customer facing solutions, is just good business sense, You do NOT want a customer’s browser to ask them if they should trust you!
User Mapping is for RADIUS and EAP, and we’re not using either this time. Quarantine is something to play with AFTER you get connections working so for now, resist the urge to click anything else except OK. Since a lot of what quarantine can do is limited to domain computers, we’re going to leave that for another post on another day.
Step Five-Configure your firewall policy
Click on View Firewall Policy for the VPN Clients Network to go back to your Firewall Policy. You can restrict access to the Internet for VPN clients, and if you put them on a different network segment than the internal, you can even limit their connections to the internal network. Since I am setting this up for trusted clients that already have full access to the internal network, and open access to the Internet, I just need to make sure that they TMG defined network “VPN Clients” is in the AllowAllOutbound rule that I created back here.
Make any desired changes to this for your level of comfort, and then click back on Remote Access Policy (VPN) to continue.
Step Six-View Network Rules
If you are connecting your VPN clients directly to the Internal network, they will be sharing the internal interface of your TMG. If you want to create a virtual subnet for VPN clients, you can either decide to route that traffic bi-directionally through your TMG, or you can NAT the VPN clients to the inside network. Here is where you define that. Since we are connecting VPN clients directly, we choose the Route option, which should be selected by default.
Step Seven-Test it out
Get a client on another network, and setup your connection from your client to your TMG using SSTP. If there is another edge device between your TMG and the Internet, you want to make sure that inbound TCP 443 is open. If all goes well, you will be prompted for your username and password. This is encrypted using MS-CHAPv2. Enter your creds and (assuming you have valid credentials for a user who is a member of a permitted group) you should be connected. Yay! If you’re not, here’s some troubleshooting tips.
You can use the live logging in TMG to focus on VPN client connections. Browse down to Logs & Reports, edit your filter to look at VPN Client sessions. I like to do this live while the client connects, but you can also look at historical records if you wish.
Always look first for authentication errors. I can’t tell you how many hours I have wasted assuming the user had good information, only to find out they didn’t. Also look for protocol errors, and make sure the client is setup for MS-CHAPv2 to match your requirements.
it means that your client does not trust the server’s certificate because it does not recognise the root CA. Obtain the root certificate from the CA, and save it to your client. Import it to the computer’s (not your user’s) certificate store as a Trusted Root Certification Authority certificate.
Try your connection again.
Remember as we mentioned above, one thing clients will do to enhance security is to verify that the certificate securing the SSTP connection has not been revoked. If you obtained a certificate from a public CA this won’t be an issue, but if you rolled your own, unless you are publishing the CRL through your TMG to the Internet, you will next see this error, 0x80092013.
Assuming you like your own certificates, and you don’t want to publish your CRL to the outside world, you can get around this with a simple registry hack. Taken from http://support.microsoft.com/kb/947054/en-us
Registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\Parameters
Registry entry: NoCertRevocationCheck
Data type: REG_DWORD
You can use this registry entry to enable or to disable the SSL certificate revocation check that the VPN client performs during the SSL negotiation phase. Certificate revocation check will be performed if the value is set to 0. If the value is set to 1, certificate revocation check will be skipped.
No reboot required. With this in place, you should be connecting in no time. If not, check your TMG logging, or leave a comment and I’ll see if I can help.
You might have noticed that I recycled some of the words and screen shots from my post on PPTP VPNs. To close that post, I used Bruce Springsteen’s 1987 hit Tunnel of Love…his best song IMHO. Seven years before, another of my favourite groups, the Dire Straits, released a song of the same name. It’s one of their lesser known hits to those who are not hardcore fans, but it is one of their best songs to those who know it. Enjoy.
Direct link for RSS and email subscribers…http://youtu.be/GrDK0UoAkfY
If you found this post useful, please consider following us on twitter. You’ll be the first to learn about new posts, and, rarely, we’ll share a comedic or witty tweet. Of course, you can also leave a comment below to let us know we hooked you up.