Azure Connect: connecting your on-premise and Windows Azure networks together.

I made a post describing how to domain-join instances you have running in the Azure cloud. This post dives in to a little of the detail underneath the covers as far as the networking that enables it all is concerned.

First: You can sign-up to the Windows Azure Connect CTP, previously known as “Project Sydney”, this calendar year. That means it’s a maximum of 53 days away! While you are using the CTP there is no charge, just like the other Windows Azure CTPs have been to-date. If you don’t already have a Windows Azure subscription to use it with, there are some instructions on how to get a free subscription in this post.

Second: Why would you want it? Well, I wrote a post about how you domain-join your Azure machines and gave examples of where this makes Windows SSO possible from your on-premise environent to apps that you have running in the cloud. Think about SQL Server and how that is typically deployed in a multi-tier Enterprise application. It will typically use Windows Integrated Authentication to access the SQL Server. This is one of the primary examples given by the product-group regarding why you’d Windows Azure Connect: to connect back to an on-premise SQL Server using Windows Integrated Authentication.

Next: How does it work?

Plug-ins and config files

It’s a combination of plug-ins that need to run on server(s) in your on-premise network and modifications to the service model (through new sections in the .cscfg file) in Windows Azure. However for the VM Role, you need to install a plug-in before you offer it to Windows Azure to run for you.

In the diagram above, all the orange parts are components of Windows Azure Connect. Starting from the on-premise environment: the computers in the on-premise environment that need to communicate with the instances in the cloud have the Windows Azure Connect Agent installed. This causes a virtual network adapter with an IPv6 address to be configured. This communicates with a Relay Service up in the cloud. There may be a NAT or a firewall at the perimeter of your on-premise network but that’s OK as long as port 443 (SSL) is open to the relay service.

There is a section in the serviceconfiguration.csdef that specifies which roles in the service are to be connected to the relay service. This is used for the Web and Worker roles. With the VM Role it is down to you to install the Windows Azure Connect Agent on to the virtual hard disk before you submit it to Windows Azure to run.

You don’t have to worry about each instance, Windows Azure Connect will take care of that for you. When you specify which roles you want to enable for Windows Azure Connect in the service definition, the fabric automatically creates VM instances with the necessary software installed and each instance automtically gets its configuration from the service model. With the VM Role, you have to ensure the software is installed before you submit it. In the case of the VM Role, the fabric is not responsible for creating the role. You create it when you submit the VHD in the first place. Multiple instances use this base VHD as the template for all subsequent instances of that role. This table summarises:

 

To enable this computer for WA Connect	Do this
On-Premise computer	Install the WA Connect Agent
Worker Role	modify .csdef
Web Role	modify .csdef
VM Role	install the WA Connect Agent

 

The WA instances are configured by entering a code in to the .cscfg. When you create a WA Connect service in the admin portal, a Service Token is generated which is unique to your service. This is the key that connects the Relay Agent with your WA Connect service.

Network Policy

The Admin portal allows for granular control over what machine can connect to what role and vice versa. You can also create groups of machines to make administration easier. Once set, security is maintained by end-to-end IPSec traversing the relay agent.

 

In the diagram, you can see 2 groups of computers in the on-premise environment, imaginatively named “Group1” and “Group2”. Network Policy has been created to allow any computer in Group1 to connect to any instance in the Web Role. Any computer in Group 2 (which is a group of one computer!) can connect to any instance in the Worker Role. Notice that all connection traverse the relay agent.

Communication between say any instance in the Worker Role and the computer in Group 2 is protected by end-to-end IPSec. So not only is there a “containing” SSL connection between the on-premise computer and the Relay Service, but there is also an encrypted channel within that “container” (I’m avoiding the word “tunnel” as I’m sure to be picked up on it by a pedant!) that enjoys protection from end-to-end.

DNS name resolution is also handled between computers connecting to the Relay Agent.

Domain-joined Azure instances

The instances in Azure can be joined to an Active directory through sections in the .cscfg file as part of the WA Connect feature-set. More detail is provided in this post.

Scenarios

There are a number of cases where this WA feature is interesting – especially for Enterprise apps where Integrated Windows Authentication is useful.

1. Enterprise Cloud Applications that need access to an on-premise SQL Server. Because all the features such applications are used to enjoying on-premise with connecting to SQL Server. Aside from the SQL Server being in a different data centre, this gives just the same environment as when the application is deployed on-premise.
2. Domain-joined applications where clients want to connect to Azure deployed, AD-integrated applications. This is detailed in the domain-joined Azure instances post I mentioned earlier.
3. Remote administration such as remote PowerShell to the instances deployed in to the cloud.

 

 

Planky

Comments

• Anonymous
  November 14, 2010
  Is there an end to end IPsec connection from the VM/host in the enterprise to the VM in Azure?  Does that then imply double encryption... IPsec and TLS?  Thinking performance here...

• Anonymous
  November 14, 2010
  Yes - that's right. I believe the SSL connection to Azure is terminated at the Relay, so the Azure instance itself won't be concerned with that encryption - only the IPSec encryption. But remember both of these technologies result in a symmetric key being used aside from the initial connection set up. It's an overhead but not a massive overhead. Planky

• Anonymous
  November 15, 2010
  Thanks a lot for the detailed write up. I have a very brief write up [www.cumulux.com/.../microsoft-azure-connect]  on the same with out the technical intricacies and have referred this article for technical reference.