One of the problems that Catapult Consultants has at times is the restrictions of outbound traffic while at a client site.  Most clients allow all outbound traffic from their locations but there are a few clients that only allow certain outbound traffic.  This has caused problems in the past with some application that use ports other than port 80 and port 443 including VPN.  One of the most used VPN protocols is Point-to-Point Tunneling Protocol (PPTP).  PPTP has been in Microsoft Windows since Windows 95 and continues to be part of Windows even in Windows Server 2008 and Windows 7.  It’s fast, it works, and there is no additional software to install.  The only problem is if you’re somewhere that doesn’t allow it then Catapult Consultants can’t connect to their office via VPN.  With the introduction of Secure Socket Tunneling Protocol (SSTP) in Windows Server 2008 it was viewed as another way to have Catapult Consultants connect to the Catapult network securely without asking a client to modify their firewall rules.  Since SSTP is so new for the Microsoft Operating System it’s only available in Microsoft Vista SP1+, Microsoft Windows 2008, and Microsoft Windows 7.  SSTP uses port 443 with SSL and almost everyplace allows outbound traffic through port 443.  It also uses certificates.  These certificates can be either private corporate ones issued by an internal CA or public certificates.  What’s also great is when a Catapult Consultant tries to connect to Catapult via VPN it will try to use PPTP first.  If it can’t connect for some reason it will try L2TP/IPsec next.  If it can’t connect that way then it will try SSTP and hopefully it will connect since SSTP is designed to work everywhere.  Looking at the Microsoft Technet Routing and Remote Access Blog ( ) it appears PPTP puts less of a load on the processor of the VPN server and VPN client.  I would imagine why that’s why it tries PPTP first. 


What’s great is end users don’t have to do a thing differently or change anything!  Everything is setup on the server and public DNS so there is nothing to configure on the clients unless they changed the default settings.  Hopefully not.    


Now let’s talk about the technical highlights and problems I experienced while implementing SSTP. 


If you’ve setup a Microsoft Routing and Remote Access Server using 2 NICs then you really don’t have to do much more to get SSTP to work.  I found an article on the Internet ( ) on how to setup SSTP VPN on a server with a single NIC but I’m not fond of setting up VPN on a server with a single NIC.  I like using two NICs.  The two articles below were very useful for me. and . 
I decided to setup a new server and test it so it wouldn’t disrupt the current VPN users.  My plan was when it was setup, tested, and working just to change the public DNS records and firewall rule.  When implementing SSTP for Catapult I had to change the certificates a few times for a few reasons.  You should have the certificates installed BEFORE you install RRAS so they will bind the right way but if for some reason you have to change the certificates two articles are very important on how to rebind and what you need to change in the registry.  One problem I experienced was I was connecting via SSTP then within 1 second my VPN connection would disconnect.  It was bound the right way but my registry settings didn’t reflect the proper SHA hash.  Once I change it I was able to stay connected.  It drove me crazy because I really don’t get an error message or anything. 


Just remember to review the articles for changes.  Also make sure you restart RRAS for all changes to take effect.  No need to reboot but just restart the service. 


One more thing.  It appears wildcard certificates work.  We couldn’t find anything on the net if they would or not but it LOOKS like they do.