通过

Azure: Knowing the limitations with Point-to-Site VPN connections via Authenticated Proxies

  • 项目

There are two options currently available for secure cross-site VPN connectivity between a virtual network hosted within Windows Azure and a client machine, namely Site-to-Site connectivity and Point-to-Site connectivity. An overview of these can be read here:

https://msdn.microsoft.com/en-us/library/windowsazure/dn133798.aspx

Essentially a Site-to-Site (S2S) connection is where a VPN device (or Routing and Remote Access Service on Server 2012) is configured to allow connections between a virtual network in Azure and a network hosted on-premises. This article is concerned with Point-to-Site connectivity, which at the time of writing is still in Community Preview mode. Point-to-Site (P2S) connectivity is used when connecting from a single client computer to a virtual network hosted in Azure. A VPN client package is installed on the client computer and the VPN connection is started manually when the user wishes to connect to the virtual network within Azure. This approach is normally used when only a handful of client computers need access to a virtual network, and VPN device configurations are out-of-scope. Whilst this is by far the easiest approach, there is a notable limitation to be aware of especially when working within a corporate network.

How it works

P2S connections use a VPN tunnel made via the Secure Socket Tunneling Protocol (SSTP) with authentication being provided by certificates. You have the option to use an X.509 certificate from a Certificate Authority, or your own self-signed root certificate with client certificates that are chained to this (using makecert or an alternative). This root certificate then needs to be uploaded to your virtual network via the Azure management portal. Once this is done, you can then download and install the appropriate VPN client package (either 32 or 64 bit) from the management portal onto the client computer you wish to connect from (this computer must have the client certificate installed on it).

Limitation

Because P2S is a connection made via SSTP, then limitations of that protocol apply. One limitation to be aware of when using P2S is when authenticated web proxies are being used on the network where the client computer resides. As SSTP does not support authenticated web proxies where authentication is required as part of a HTTP CONNECT command, the P2S connection attempt will fail. You can use Fiddler to view the connection being attempted to troubleshoot. On a machine not using an authenticated proxy, you should see the following:

Figure 1 - HTTP CONNECT issued when P2S connection established

Figure 2- HTTP CONNECT with no authorization headers present

If the HTTP connections are traversing a web proxy that required authentication as part of the request, you should be able to view and troubleshoot in the Auth tab.

Workaround

Within a corporate network, the only way to work around this issue is to provide an exception to the authentication proxy, whereby the address being used for the Azure virtual network is allowed to pass through the proxy without being authenticated. This would involve adding a configuration entry to the web proxy to allow connections to address used by the P2S connection to be unauthenticated by the appropriate web proxy.

The address you need to specify is 'azuregateway-[guid].cloudapp.net' where the 'guid' section is the one unique to the subscription you're using. This address will resolve to the Gateway IP address associated with the virtual network in Azure. Once the address has been added as an exception, the VPN connection can be started successfully.

A key point to highlight here is that the decision to do this obviously does have to be weighed correctly to see whether it fits within the corporate environment within which you are working; the VPN connection is still secure (via SSTP and the certificates) but the proxy pass-through is unauthenticated.

Written by Dan Marzolini

Comments

  • Anonymous
    January 07, 2015
    What?? Why use SSTP that is supposed to pass through proxies and whatnot because it use a CONNECT 443 method if the NTLM negotiation FAILES to ISA proxy level? The NTLM challenge fails because the stupid client does not send the domain user authentication, instead it only send host information in response to the challenge BEFORE the actual SSTP connection even takes place. If the client use the correct NTLM exchange this wouldn't be a problem at all.