Adding the SSTP Magic to the UAG Charm

Adding the SSTP Magic to the UAG Charm

  • Comments 4
  • Likes

One of the interesting features in this Forefront UAG release is our integration with SSTP (Secure Socket Tunneling Protocol) – a firewall-friendly VPN technology introduced into Windows in Vista SP2. SSTP is another RRAS (Routing and Remote Access) tunneling protocol, which relies on standard SSL technology for implementing a ‘layer 3 VPN’.

Supporting layer 3 VPN to enable remote users full access into the corporate network is not new in UAG – it’s supported in IAG via the Network Connector component that resides on both the user’s endpoint machine and the IAG server. However, Network Connector is a proprietary technology which is being replaced by the SSL-based in-box technology. That replacement brings several benefits:

  • Saves installation of a driver on endpoint machines
  • Scalability gains (requires a single HTTPS connection to the UAG server)
  • Supports DHCP for VPN client IP provisioning

Network Connector is still supported in UAG, primarily for down-level clients (more on that a bit later in this blog), but the direction is clear: rely on standard platform technologies where possible.

“Sounds great – show me how!” – configuring UAG\SSTP has 3 steps:

 

Step 1 - Enablement

The first step is enabling SSTP, and it’s performed by launching the “SSL Tunneling Configuration” dialog via Admin->Remote Network Access->SSL Network Tunneling (SSTP):

pic1 

  • In the “General” tab you specify the max number of client connections and choose a trunk to rely on. That trunk must already exist, and SSTP would pull several elements from that trunk, like its public hostname (for the clients to dial to), port and server certificate (which must be valid).
  • The Protocols tab is pretty straightforward – you just make sure the SSTP protocol is checked (which it is by default) and the rest (PPTP and L2TP/IPSEC) are not as these two are not supported in this beta.
  • The IP Address Assignment is more interesting, as here is where you configure the policy of assigning IP addresses to VPN clients. We support two modes: static and dynamic via DHCP. In the case of static, you will notice that you’ll need to exclude the IP range from the definition of your internal network - you’ll get an error message if you don’t.
  • Access Control is preserved for dial-up scenarios which are not supported in beta – please leave it blank.

 

Step 2 - Publishing

The second step is publishing the Remote Network Access app. You use the standard “Add Application Wizard” for that- you’ll find the Remote Network Access app, alongside Network Connector,  in the “Client/Server and legacy” dropdown list.

pic2

This is a good opportunity to elaborate about why Network Connector is still relevant and supported in this release: as mentioned above, SSTP is only supported on Vista SP2 clients and above. When an end-user launches the Remote Network Access app from the trunk, a client-side logic determines if the client OS version is Win 7 or a previous version. In the former case SSTP will be used to establish a connection; in the latter – NC (assuming NC is also enabled on UAG). You might be wondering why we’re using NC on a Visa SP2 client machine; the reason is to provide a single sign-on experience. Let me elaborate a bit: typically when a user dials-into RRAS\SSTP she needs to undergo some kind of authentication. But in the scenario where the user has already logged into the UAG trunk, and launched Remote Network Access from there, we don’t want her to need to provide log-in credentials to RRAS again; that’s why we’ve implemented an RRAS admin plug-in that delegates authentication and authorization decisions to UAG. Now comes the tricky part: that plug-in is only supported on Win 7 clients, not on Vista SP2 clients. Hence, we’ve made a decision to treat Vista SP2 as ‘legacy’ for this case, and use NC.

 

Step 3 - End-user Testing

The last step is, well – just try it out. Log in to the trunk and launch the Remote Network Access app (or whatever name you gave to that app during the publishing phase). You will see a dialog showing the connection attempt, and if successful – a “connection started” bubble:

pic3

That’s pretty much it – you’re connected and can ping and browse internal resources. You can end the connection from the Portal Activity window or by just logging off from the portal.

Happy networking,

Asaf Kariv | Lead Program Manager | Microsoft Unified Access Gateway

Comments
  • When publish "Remote Network Access", which server should point to on Server Setting in wizard??

  • I follow your setup  but I use a pool addresss  but I can't ping or  browse internal resources  My connection is succesfull but cant access the internal network  notice  that I was given 255.255.255.255  submask but the internal network  is using submask 255.255.0.0

  • the connection ended on the spot and i didnt get any IP ?

  • That’s pretty much it – you’re connected and can ping and browse internal resources. You can end the connection from the Portal Activity window or by just logging off from the portal.

    Happy networking,

    Asaf Kariv | Lead Program Manager | Microsoft Unified Access Gateway

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment