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.
Step Three-Authentication
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.
Then click the Protocols tab. Check the box to Enable SSTP, and select your HTTPS listener.
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.
Since SSTP does involve certificates, there are some other issues that might come up. If you see this error, 0x800B0109
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, 0×80092013.
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
NoCertRevocationCheck
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.
Applied the register hack , reboot the sstp server, still get the problem 0×80092013
revocation server offline
Hi Gordon,
Just to be clear, you did apply that registry hack to the client, right?
Ed
I applied it to server , that is why failed.
then I applied it to client , it success, thank you.
But I cannot accept apply this to client in production env, because that will broken the security of client to all other websites.
Is there any way we dont need do this hack? that look useless.
Hi Gordon,
I’m glad that you got this working. Great job. As to the need for this reg hack…
you only need to do this if you are going to use a self-signed certificate, or one from your Enterprise AND you are not going to make your CRL publishing point accessible from the Internet.
For production, if you buy an SSL certificate from Thawte or one of the other commercial CAs, you won’t have to do this. This is what I recommend doing.
Also, this hack ONLY applies to certificate checking by the SSTP client…any other certificate checking by your browser(s) will still happen as normal.
Cheers,
Ed
Hi Ed Fisher,
Thank you very much.
Since this require client manually install the CA , I will not apply it for others like Email or WebServer.
Only the SSTP client I would like them install the CA manully to improve the security . so that even someone know the username and password for SSTP , they still cannot connect to my office because they cannot get the CA.
Whoops, Gordon, that is not how this works. The client checks the validity of the certificate to ensure that the server it is connecting to has not been compromised, which the reg hack will turn off. This does NOT act as another authentication factor for the client. If you want to make sure that an attacker with a valid username and password cannot get in, then you need to look at using EAP/TLS for your authentication and implementing a two factor solution. Smart cards and RSA tokens are perhaps the most well-known, but there are other systems available. Since EAP/TLS is a ‘plug in’ type of authentication, anything that works with this should work with SSTP, but I don’t have the budget to test this at home so I cannot write a post on it. Hope this helps.
Ed
Hi Ed,
Great post. I am trying to set up excatly the same config using TMG and a Thawte public certificate but I still get 0×80092013 errors.
it’s driving me crazy and I’ve tried installing root & intermediate CAs on both client and server. I don’t really want to hack every client’s registry if I can avoid it (although it does work).
Running certuil -verify -urlfetch completes successfully so I’m stumped! Any ideas?
Cheers.
Hi Richard,
Have you tried using certutil to verify the certificate from one of your clients? I am considering the possibility that it verfies for you, but not for them, either because you have more access, or they have less. If you want me to take a look at the client side, send me a message via the contact form with the hostname for your VPN. I don’t want or need a userid, I just want to do an initial connection to see what my client sees.
HTH
Ed
Hi Ed,
I sent you a message through the contact form… many thanks in advance!!
Richard.
Richard,
Sorry for the delay, but work actually intruded on home time
Here’s a snip from the very end of what I get when I try to verify your cert from my workstation:
A certificate chain could not be built to a trusted root authority. 0x800b010a (-2146762486)
————————————
Incomplete certificate chain
Cannot find certificate:
CN=Thawte SSL CA, O=”Thawte, Inc.”, C=US
Cert is an End Entity certificate
ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation beca
use the revocation server was offline. 0×80092013 (-2146885613)
CertUtil: The revocation function was unable to check revocation because the revocation server was offline.
CertUtil: -verify command completed successfully.
And to confirm error 0×80092013
C:\Users\efisher\Desktop>err 80092013
# for hex 0×80092013 / decimal -2146885613 :
CRYPT_E_REVOCATION_OFFLINE winerror.h
# The revocation function was unable to check revocation
# because the revocation server was offline.
# 1 matches found for “80092013″
First, please check your certutil results to make sure you’re not missing the error before it says successful, and let me know what you see. The AIA, OCSP, and the CRL all seem to come down for me without any issue, but if I cannot verify revocation, my SSTP VPN client won’t connect either. You might need to open a ticket with Thawte if this continues. From what I can see without actually making a VPN connection to your system, your clients are behaving correctly.
Ed
Thanks Ed.
You are right… I must have skipped to the successful bit!
I’ll open a support case with Thawte but suspect they will tell me to install the intermediate cert on all my clients which is impractical as they are non-technical users with their own PCs around the world.
I suppose I could try another CA if need be.
Thanks again!
Richard.
Richard,
Before you buy another cert, check with Thawte. I am running Windows 7 and I had the intermediate cert in my store already. I don’t recall ever having to install a Thawte intermediate manually. If your clients do not have that cert, you can push an intermediate cert out to them through a GPO as long as those machines connect to a domain controller at some point. And, the intermediate cert verifies without any issue for me.
Personally, I love Thawte and always use them for certs. Their customer support is excellent…it’s worth your time to call.
Please reply back to let me know how things work out for you.
Ed
Hi Ed,
Bad news I’m afraid…. Thawte using an Intermediate CA in the way they currently do means that the Intermediate cert does need to be installed on every client PC for SSTP to work.
There is a nod towards it here from Thawte: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO15171&actp=search&viewlocale=en_US&searchid=1282614432001
…but the SSTP client does not seem to check Intermediate certs the same way as IE does for example.
Installing an intermediate cert is no drama with GPO if users will connect to a domain as you say but mine won’t be in a domain and getting them to install it manually would be a nightmare.
There is more info here:
http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/629280b0-bc84-49c6-8846-6b6183775277/
(skip to Paul Adare’s post on Mon, 28 Mar 2011 09:21)
Thanks again for your help!
Thank you very much! I was stumped with the revocation checking….the reg hack did the trick! Many thanks!
Happy to help!
I still have a connection error. TMG does not log anything and the client shows the error 0x800704D4: The network connection was disconnected by the local system (original message in german). I tried different manuals and always the same error…
That’s “network connection aborted by the local system.” Check the firewall logs to see if something is tripping the IPS functionality.
[...] are a couple of great articles over at retrohack.com that go over setting up PPTP and SSTP on the server side. If you are interested in setting up a VPN server, check them out and see what [...]
[...] are a couple of great articles over at retrohack.com that go over setting up PPTP and SSTP on the server side. If you are interested in setting up a VPN server, check them out and see what [...]