Category Archives: Virtual Network

Setting Static IP addresses in a Microsoft Azure Virtual Network with PowerShell

I have finally had a chance to update the Windows Microsoft Azure PowerShell Guide.

The page is about the new functionality of assigning a static IP address to a virtual machine deployed in a Virtual Network.

Setting Static IP Address on Microsoft Azure Virtual Machine

Copy a Windows Azure Virtual Machine Between Subscriptions

While working on some recent training content focused on development and test with Windows Azure Rick Rainey and I thought a great scenario would be to have a script that can copy a single Windows Azure Virtual Machine from a source subscription to a destination subscription. This script will also copy a virtual machine between data center locations. There are tons of scenarios where this can be useful for dev/test so I will not enumerate them all here :)

Using the Script

This script uses the Windows Azure PowerShell cmdlets so they must be installed prior to use. Also, both the source and destination subscription must be configured for PowerShell access prior to use. See the following for information on getting started with the Windows Azure PowerShell Cmdlets.

  # Copy a virtual machine to a different subscription (no VNET)
  .\vmcopy.ps1 -SourceSubscription "source subscription" ` 
             -DestinationSubscription "destination subscription" ` 
             -VirtualMachineName "existingvmname" ` 
             -SourceServiceName "sourcecloudservice" ` 
             -DestinationServiceName "destinationcloudservice" ` 
             -DestinationStorageAccount "destinationstorageaccount" ` 
             -Location "West US" 
 
 
  # Copy a virtual machine to a different subscription and specify an existing virtual network and subnet. 
  .\vmcopy.ps1 -SourceSubscription "source subscription" ` 
               -DestinationSubscription "destination subscription" ` 
               -VirtualMachineName "existingvmname" ` 
               -SourceServiceName "sourcecloudservice" ` 
               -DestinationServiceName "destinationcloudservice" ` 
               -DestinationStorageAccount "destinationstorageaccount" ` 
               -VNETName "DestinationVNET" ` 
               -SubnetName "DestinationSubnet"

The script can be downloaded from within the TechNet Script Center: Virtual Machine Copy Script.

If you find any issues with the script or would just like to make it better we have it posted in GitHub as well: GitHub – Virtual Machine Copy Script and are interested in pull requests for improvements.

Of course, if you would like deeper training on Windows Azure to learn how to write scripts like this yourself we would be happy to help :)

Connecting Clouds – Creating a site-to-site Network with Amazon Web Services and Windows Azure

Connecting Windows Azure to Amazon AWS

In this post I will show how you can use a Windows Azure Virtual Network (VNET) to create a site to site IPsec tunnel to connect to a Virtual Private Cloud (VPC) hosted in Amazon Web Services (AWS). Using this setup you can literally have workloads in each cloud with full VM to VM connectivity over a secure IPsec tunnel. This scenario could easily be used for failover, backup or even migration between providers. The software VPN solution I chose for testing is Open Swan.

Creating a VPC in Amazon AWS

Starting on the Amazon side create a virtual private cloud (VPC) which is the equivalent to a virtual network in Windows Azure.

VPC Creation Wizard – Single Public Subnet with Internet Gateway

create-vpc-wizard-rs

I’m choosing the 10.0.0.0/16 address space for the Amazon VPC network.

create-vpc-wizard-complete

Provision an EC2 instance that will be used to host Open Swan and be the Amazon side of the tunnel.

Launch Ubuntu 13.04 into the VPC Subnet

launch-ubuntu-instance-1

Specify the subnet of the VPC previously deployed and I would advise bumping up the instance size to Small from Micro.

launch-ubuntu-instance-2

Once the instance is created switch to the EC2 view and allocate a new Elastic IP. This will be the public IP address you will connect to the VM using SSH and the IP address your Windows Azure Virtual Network will connect to.

Click Yes Allocate on the new Elastic IP dialog.

allocate-elastic-ip

Select the instance from the drop down and click Yes Associate.

associate-elastic-ip-instance

Creating the Windows Azure Virtual Network

Before configuring the Open Swan service I need to create the other side of the network in Windows Azure. To establish the IPsec tunnel Open Swan needs the gateway IP address and authentication key which both from the Windows Azure Virtual Network.

Create a Windows Azure Virtual Network

create-vnet

Specify Data Center Location and VNET/Affinity Group Name

create-vnet-1

Check site-to-site VPN

create-vnet-2

Define the onsite network properties which in this case is the Amazon VPC Address Space and Elastic IP of the Open Swan Server

create-vnet-3

Define the Windows Azure Address Space. Ensure you add the Gateway Subnet.

create-vnet-4

Creating the Windows Azure Virtual Network Gateway

Once the Virtual Network is created open it and click create gateway -> and select static routing.

azure-create-gateway

Once the gateway is created you can get the gateway IP address and the authentication key and configure Open Swan on the Amazon side.
You will need the gateway IP and the key on the Amazon side.

azure-gateway-created

Configuring Open Swan in Amazon Web Services

Connect to the Open Swan VM

Switch to the instances view, select your instance and on the Actions menu click Connect.

Select Connect with a standalone SSH client.

connect-to-instance

Copy the SSH command (or use Putty using the instructions on the screen) to connect via SSH. I’m using the Windows SSH client that comes with GitBash for the record :)

connect-via-ssh

Once connected install and configure Open Swan for the VPN solution on the Amazon side.

Installing Open Swan

  sudo apt-get install openswan

Select NO for installing a certificate since we will be using key based authentication.

open-swan-install-1

The next steps require you to use a text editor to modify some configuration files. If you are rusty on using Linux editors like vi here is a handy cheat sheet: VI Cheat Sheet

Edit the ipsec.conf file

   cd /etc
   sudo vi ipsec.conf

Once open, enter edit mode by pressing: *i (in that order)

Replace the existing configuration with the following:

config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.0.0.0/16
      oe=off
 
include /etc/ipsec.d/*.conf

Exit and save the file by pressing: : x (in that order)

Change to the ipsec.d directory and create a new file named amznazure.conf.

  cd ipsec.d
  sudo vi amznazure.conf

Contents of amznazure.conf

conn amznazure
   authby=secret
   auto=start
   type=tunnel
   left=10.0.0.28
   leftsubnet=10.0.0.0/16
   leftnexthop=%defaultroute
   right=[WINDOWS AZURE GATEWAY IP]
   rightsubnet=172.16.0.0/16
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no

Notes about the above configuration:

  • left= is the local IP address of the Open Swan Server
  • leftsubnet= is the local address space of the servers in the VPC
  • right= is the IP Address of the Windows Azure VNET Gateway (replace with your own)
  • rightsubnet= is the address space of the Windows Azure Virtual Network

Once you have specified the configuration you need to specify the authentication key.

  cd /etc  
  sudo vi ipec.secrets

Add a line to the file in the following format (do not add the [] brackets):

10.0.0.28 [WINDOWS AZURE GATEWAY IP] : PSK "[WINDOWS AZURE GATEWAY KEY]"

Next, enable enable IP forwarding to the Open Swan VM:

sudo vi /etc/sysctl.conf

Then uncomment this line:

net.ipv4.ip_forward=1

Apply the changed network setting.

sudo sysctl -p /etc/sysctl.conf

Next, disable source / destination checking on the Open Swan server.

change-source-dest-check

disable-source-dest-check

Modify Security Groups to Allow Traffic from Windows Azure

In the Amazon management console select Security Groups and -> amzn-azure-group.

Add two custom UDP inbound rules – one for 500 and one for 4500 using the Windows Azure GW IP with /32 as the CIDR.

amzn-security-group

 sudo service ipsec restart

Windows Azure Virtual Network Connected to Amazon AWS Virtual Private Cloud

amzn-azvnet-connected

Configuring Routing

The reason the software VPN solution needs to be on the Amazon AWS side is because the AWS networking stack supports configuring routing tables where Windows Azure does not (yet I assume).

In the Amazon management console switch back to the VPC view and select route tables.

Select the route table associated with your VPC and add a new route to the 172.16.0.0/16 (Windows Azure Network) and that routes traffic through the instance ID of the Open Swan Server.

Updating Route Information

update-route-table

Creating Instances to Test Connectivity

Create an instance in AWS on the VPC Subnet.

launch-into-subnet

Launch an instance in Windows Azure on the Virtual Network created.

launch-into-vnet

One both instances are up you will need to enable the ICMP rule on each VM to test out connectivity using PING.

Pinging an Azure VM from an Amazon VM over the IPsec Tunnel

ping-from-amzn

Pinging an Amazon VM from an Azure VM over the IPsec Tunnel

ping-from-azure

That is it!

I can now deploy applications into Amazon AWS and Windows Azure and communicate between the two on a secure IPsec tunnel over the Internet.

Connecting Web or Worker Roles to a Simple Virtual Network in Windows Azure

In this post I’m going to show you how simple it is to connect cloud services to a virtual network.

Before I do that let me explain a couple of reason of why you would want to do this.

There are a few use cases for this.

Web or Worker Roles that need to:

  1. Communicate with a Virtual Machine(s)
  2. Communicate with other web or worker roles in a separate cloud service (same subscription and region though)
  3. Communicate to an on-premises network over a site to site VPN tunnel (not covered in this post)

In at least the first two cases you could accomplish the connectivity by opening up public endpoints on the cloud services and connecting using the public IP address. However, this method introduces latency because you are making multiple hops over each cloud service load balancer. Not to mention that there is a good chance that the endpoint you are trying to connect to would be more secure if it wasn’t exposed as a public endpoint. Connecting through a VNET is much faster and much more secure.

For this example I’m going to walk through a simple VNET that will accomplish the goal of connecting cloud services.

Step 1: Create an affinity group for your virtual network in the region where your cloud services will be hosted.


Step 2: Create a simple virtual network and specify the previously created affinity group along with a single subnet network configuration.

For the subnet details I am specifying 10.1.0.0/16 which is a class B address space. I’m only carving one subnet (10.1.1.0/24) out of the address space to keep things simple. Unless you need connectivity back to on-premises or are planning to lock down traffic between subnets when Windows Azure supports ACLs this will likely be a sufficient solution for simple connectivity.

Step 3: Deploy a Cloud Service to the VNET.

Unlike deploying a Virtual Machine you cannot specify virtual network settings on provisioning through the portal. The networking configuration goes inside of the .cscfg file of your Windows Azure deployment package.

To connect to this virtual network all you would need to do is paste the following below the last Role tag in your service configuration file (.cscfg) and deploy.

[sourcecode language="xml"]
<NetworkConfiguration>
<VirtualNetworkSite name="SimpleVNET" />
<AddressAssignments>
<InstanceAddress roleName="MyWebRole">
<Subnets>
<Subnet name="AppSubnet" />
</Subnets>
</InstanceAddress>
</AddressAssignments>
</NetworkConfiguration>

A few things to note about this configuration. If you have multiple roles in your deployment package you will need to add additional InstanceAddress elements to compensate. Another thing to point out is the purpose behind multiple subnets for each role. The idea is if you have an elastic service that has instances added/removed you could conceivably run out of addresses in the subnet you specify. If you specify multiple subnets to the role Windows Azure will automatically pull an address out of the next available subnet when the instance is provisioned if you run out of addresses from the first subnet.

Name resolution is another area to address. When deployed inside of a virtual network there is no default name resolution between instances. So if you are deploying a web role that will connect to a SQL Server running on a virtual machine you will need to specify the IP address of the SQL server in your web.config. For that specific scenario it would make sense to deploy the SQL VM first so you can actually get the internal IP address for your web app. It is of course possible to deploy your own DNS server in this environment. If you do you can specify the DNS server for your web/worker role instances with an additional XML configuration.

This would go right below the NetworkConfiguration element start tag:

[sourcecode language="xml"]
<Dns>
<DnsServers>
<DnsServer name="mydns" IPAddress="10.1.1.4"/>
</DnsServers>
</Dns>

Finally, to make a truly connected solution you would want to deploy additional services such as VM or other cloud service/web worker roles to the VNET. The beauty of this configuration is every application deployed into this VNET will be on the same virtual network and have direct low latency and secure connectivity.

P.S. Virtual Network and Subnet Names are case sensitive in the configuration file.

Connecting Windows Azure Virtual Machines with PowerShell

In my post on automating virtual machines I showed the basics for getting around and managing aspects of Windows Azure VMs. In this post I want to cover a few of the more complex scenarios such as connectivity between VMs, deploying into a virtual network and finally deploying a virtual machine automatically domain joined into an Active Directory Domain.

Connecting Virtual Machines

So far we have seen details on provisioning a single virtual machine. What happens if your application requires more than one VM? How to connect them? There are two options for connecting virtual machines. The first is to add multiple virtual machines to the same cloud service and the second is to provision each VM into the same virtual network. When machines are added to the same cloud service and are not within a virtual network they receive the benefits of being on the same network and receive built in name resolution with each other through Windows Azure provided DNS.


So how do you add two virtual machines to the same cloud service? When you create the first virtual machine using New-AzureVM or New-AzureQuickVM you are required to specify the -Location or -AffinityGroup parameter. When you specify either parameter it tells the cmdlets that you wish to create the cloud service at that time because the data center location can only be set on initial creation. To tell the cmdlets to create the VM in an existing cloud service you just omit the -Location/-AffinityGroup parameter.

Create a VM and a New Cloud Service (specify -Location/-AffinityGroup)

New-AzureVMConfig -ImageName $img -Name $vmn -InstanceSize Small | 
	Add-AzureProvisioningConfig -Windows -Password $PWD |
	New-AzureVM -ServiceName $svc -Location $loc

Create a VM and Adds to an Existing Cloud Service by (omit -Location/-AffinityGroup)

New-AzureVMConfig -ImageName $img -Name $vmn -InstanceSize Small | 
	Add-AzureProvisioningConfig -Windows -Password $PWD |
	New-AzureVM -ServiceName $svc

Connecting Virtual Machines with Windows Azure Virtual Networks

The second way of provisioning connected virtual machines is by using a Windows Azure Virtual Network. With a Windows Azure Virtual Network the network can span cloud services. This enables scenarios such as virtual machines (or web and worker roles) in different cloud services to be fully connected in the cloud.

How do you provision VMs into a VNET with PowerShell?

Just like the -Location parameter a VNET can only be specified when creating the first VM in a cloud service (note that the subnet for each VM can be set per VM on provisioning). Additionally, VNETs require that the cloud service be deployed into the same affinity group as the VNET was created in. The New-AzureVM cmdlet requires -AffinityGroup instead of -Location when deploying to a VNET.

Joining a Virtual Network at Provision Time

New-AzureVMConfig -ImageName $img -Name $vmn -InstanceSize Small | 
	Add-AzureProvisioningConfig -Windows -Password $PWD |
       Set-AzureSubnet 'subnet' |
	New-AzureVM -ServiceName $svc -AffinityGroup 'myag' -VNetName 'VNET'

Specifying DNS

One of the significant differences between deploying a virtual machine outside of a VNET and one within is inside of a VNET there is no Windows Azure Provided DNS for VM to VM name resolution. To provide for this you are allowed to specify DNS servers inside of the Virtual Network configuration. When deploying with PowerShell you also have the ability to specify DNS settings when you create the first VM. This is a very flexible approach because it allows you the ability to specify DNS at deployment time without the need to modify the underlying virtual network configuration.

Specifying DNS Server on Provisioning

In this example I am creating a DNS object that references a DNS server (10.1.1.4) and I specify it with New-AzureVM. All VMs created in this cloud service will inherit this DNS setting on boot.

$dns = New-AzureDns -Name 'onprem-dns' -IPAddress '10.1.1.4'
New-AzureVMConfig -ImageName $img -Name $vmn -InstanceSize Small | 
    Add-AzureProvisioningConfig -Windows -Password $PWD |
    Set-AzureSubnet 'subnet' |
    New-AzureVM -ServiceName $svc -AffinityGroup 'myag' -VNetName 'VNET' -DnsSettings $dns

Deploying a Virtual Machine into an Active Directory Domain

With Windows Azure Virtual Machines it is entirely possible to have a full Active Directory environment in the cloud. AD can either be hosted on-premises with connectivity provided by a site-to-site VPN tunnel using Windows Azure Virtual Networks OR you can host an AD domain directly in the cloud.

Once AD connectivity is in place you can use the PowerShell cmdlets to automatically join a Windows Virtual Machine directly to an Active Directory domain at provision time. For AD domain join to work you must specify the DNS server IP address for your Active Directory domain.
In this example New-AzureDNS is used to specify the DNS for the VM to point to an AD DNS Server in the cloud (10.2.0.4) which itself has been configured to point to an on-premise AD server (192.168.1.6) in a previous deployment. Setting DNS at this level is also useful because any future VMs added to this cloud service will inherit the DNS setting.

$subnet = 'APPSubnet'
$ou = 'OU=AzureVMs,DC=fabrikam,DC=com'
$dom = 'fabrikam'
$domjoin = 'fabrikam.com'
$domuser = 'administrator'
 
$domVM = New-AzureVMConfig -Name 'advm1' -InstanceSize Small -ImageName $image |      
	Add-AzureProvisioningConfig -WindowsDomain -JoinDomain $domjoin -Domain $dom -DomainPassword $pass -Password $pass -DomainUserName $domuser -MachineObjectOU $ou | 	
	Set-AzureSubnet -SubnetNames $subnet
 
$dns = New-AzureDns -Name 'clouddc-ad' -IPAddress '10.2.0.4' 
 
New-AzureVM -ServiceName 'app-cloudservice' -AffinityGroup 'ADAG' -VNetName 'HybridVNET' -DnsSettings $dns -VMs $domVM

If you would like to try some of this out on your own I highly suggest the Windows Azure Training Kit as a starting point. There are many hands on labs including deploying Active Directory and connecting multiple virtual machines.

Windows Azure IaaS Overload

I took a short breather after TechEd North America and TechEd Europe back-to-back but I did want to put up a post to summarize the sessions around Windows Azure Virtual Machines and Virtual Networks from TechEd 2012. This is a big and extremely important launch for Windows Azure so we have quite a bit of coverage on the subject :)

If you were looking for a crash course on Windows Azure IaaS here it is!


Meet the New Windows Azure – Scott Guthrie

Windows Azure Virtual Machines and Virtual Networks – Mark Russinovich

Windows Azure IaaS and How it Works – Corey Sanders

Extending Enterprise Networks to Windows Azure using Windows Azure Virtual Networks – Ganesh Srinivasan

Deep Dive on Windows Azure Virtual Machines – Vijay Rajagopalan

Running Linux on Windows Azure Virtual Machines – Tad Brockway

Migrating Applications to Windows Azure Virtual Machines – Michael Washam

Deploying SharePoint Farms on Windows Azure Virtual Machines – Paul Stubbs

Migrating SQL Server database applications to Windows Azure Virtual Machines – Guy Bowerman, Madhan Arumugam

Running Active Directory on Windows Azure Virtual Machine – Dean Wells

How to Move and Enhance Existing Apps for Windows Azure – Tom Fuller, Greg Varveris, Purush Vankireddy

Upcoming Presentations on Windows Azure

I have a few upcoming sessions planned for presenting on Windows Azure Virtual Machines.

The first is a FREE all-day Microsoft Cloud Day conference in London (UK) on Friday, June 22nd to learn about Windows Azure and Windows 8 where I will be talking about Windows Azure Virtual Machines and Virtual Networks.

I have quite a bit going on at TechEd Europe in Amsterdam as well.

Migrating Applications to Windows Azure Virtual Machines
This session is in D204 on Thu, Jun 28 12:00 PM – 1:15 PM.

The focus is on how you can pick up existing workloads and move them into the cloud using Windows Azure Virtual Machines (without re-writing your app!).

Windows Azure Virtual Machine Workshops
I will also be delivering two hands on workshops about deploying virtual machines that give you a two hour crash course on deploying a multi-vm application using VMs.

However, to get the inside scoop make sure you attend Mark Russinovich’s session on Windows Azure Virtual Machines and Virtual Networks in Theater on Tue, Jun 26 12:00 PM – 1:15 PM.

Of course, if you can’t make it you can see the recorded session from TechEd NA here: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/AZR209. If you haven’t familiarized with the new Windows Azure IaaS features yet this is the place to start.

Thanks!
Michael