My name is Daniel Campos, and I am a program manager intern on the RemoteApp team. On May 12th, we announced the availability of the preview for the Microsoft Azure RemoteApp Service. Some of our customers asked for more information on how to connect Azure RemoteApp to their existing Azure VNET.
This tutorial walks you through the steps of linking Azure RemoteApp to an existing VNET in Azure. During this tutorial we will be referring to the “RemoteApp VNET”, where Azure RemoteApp lives and the “Backend VNET”, where you have your AD/Server or other VMs running. After you have configured your VNET to VNET connection you will be able to link your Backend VNET to other networks (on-prem networks and/or other VNETs) by setting up another IPSEC tunnel with dynamic routing enabled. Note that as of now you will not be able to connect your Backend VNET to another network using static routing or ExpressRoute.
I suggest that you fill out a table like the one below so you have your numbers easily available. For my address spaces, both for my Azure VNET and RemoteApp VNET I choose 10.1.0.0/19 and 10.2.0.0/19 for simplicities sake. You should check your VM and VNET specific requirements before settling on a size.
DNS IP(must be in backend address space)
Backend VNET Address Space
RemoteApp VNET Address Space
Gateway IP for Backend VNET
Gateway IP for RemoteApp VNET
For the purpose of this tutorial I will be starting from scratch. If you already have an Azure VNET, it will only work if you have created a Dynamic Routing Gateway for it. If you created your Backend VNET with a Static Gateway you will need to create a new Backend VNET. If your Backend VNET meets this criteria you may skip to step 2.
1. Create a Backend VNET
a. NEW -> NETWORK SERVICES -> VIRTUAL NETWORK -> CUSTOM CREATE
b. Choose a name and a location for your backend VNET.
c. Enter your DNS server’s IP address.
d. Select an address space for your VNET. In my case my Backend VNET will be 10.1.0.0/19 and my RemoteApp VNET will be 10.2.0.0/19.
2. Prepare Backend VNET for VPN.
a. NEW -> NETWORK SERVICES -> VIRTUAL NETWORK -> ADD LOCAL NETWORK
b. At this point you need to feed the local network a random VPN device IP as our RemoteApp VNET does not exist yet.
c. The Address space must be identical to the address space you will be assigning to your Azure RemoteApp VNET. In my case that will be 10.2.0.0/19.
d. After the local network has finished creating, switch back to your recently created backend VNET.
Click the CONFIGURE tab.
Click the Connect to the local network checkbox and choose the local network you just created from the LOCAL NETWORK dropdown.
Scroll down to the virtual network address spaces section for the VNET, click add gateway subnet and click SAVE when done. Wait about a minute as your network updates.
e. Go back to the VNET dashboard tab and click CREATE GATEWAY in your VNET, two options will pop up, click on Dynamic Routing and prepare to wait, gateway creation is usually about 15-30 minutes.
f. After gateway creation had finished your VNET should resemble what is below.
g. At this step you will want to update your table with the Gateway IP address.
DNS IP(must be in backend)
3. Create RemoteApp VNET
a. NEW -> APP SERVICES -> REMOTEAPP -> CREATE WITH VPN
Should look like this
b. Next you need to create a RemoteApp virtual network for the RemoteApp Service. From the RemoteApp main screen select the VIRTUAL NETWORKS tab and click CREATE A REMOTEAPP
c. Place the RemoteApp VNET in a region close to your backend VNET for best performance.
d. Remember the Virtual Network Address Space will be the address space where your Azure RemoteApps Live (i.e. RemoteApp VNET) and the Local Network Address Space is your backend VNET. These 2 must not overlap.
e. Next enter your DNS Servers IP address and the VPN IP address that we generated earlier in our Gateway creation (22.214.171.124 for me). You will need to make sure you choose DYNAMIC routing and then you can finish creating your RemoteApp VNET. You will need to wait 15-30 minutes for the RemoteApp VNET to provision.
f. After the VNET is done provisioning you will need to write down your shared key and Azure Gateway IP Address. Click on the MANAGE KEY button at the bottom of the screen to obtain this information.
g. At this point you should update your table with the Azure Gateway IP address and the shared key.
DNS IP(must be in backend
4. VNET to VNET Connectivity
a. NETWORKS -> LOCAL NETWORKS
Click EDIT at the bottom of the page once you have selected your Local Network
b. Replace the VPN Device IP Address with the Azure RemoteApp Gateway IP you just wrote down and click on through to update your local network.
c. Run the Azure PowerShell cmdlets
i. Download/Install Azure PowerShell Module: http://azure.microsoft.com/en-us/downloads/
ii. Launch Windows Azure Powershell.
iii. Add your Azure Account by running add-azureaccount. Be sure to select your subscription that contains your Backend VNET.
iv. Run Set-AzureVNetGatewayKey –VnetName <Backend VNET Name> -LocalNetworkSiteName <LocalNetwork> -SharedKey <Use the Key you just wrote down> This will take about 2-5 minutes to finish running. When it is done and successful your command shell should resemble mine.
d. After that has finished navigate back to the VNET Dashboard page and in your appropriate VNET click CONNECT, within about 2 minutes Azure will finish connecting.
e. After waiting another 5 minutes and refreshing the networking page, there should be traffic between the two. You are now able to use RemoteApp to connect with Azure VNETs.
f. Your RemoteApp VNET should switch to be in a ready state about 5-10 minutes after you see that the VNETs are connected.
Now that your RemoteApp VNET is connected to your backend VNET you will be able to move forward with setting up your RemoteApp Hybrid Instance. Stay tuned for more blog posts and release updates for Azure RemoteApp in the near future.
We have an existing VNET linking on premises to backend cloud resources. Our on premises VPN device is a Watchguard, which does not support Dynamic routing, so the VNET has been configured with static routing. The example you've given shows how to create a new VNET for backend resources, and link it to a dedicated RemoteApp VNET - however, both gateways are dynamic. Is there any means for us to link a RemoteApp VNET in our scenario?
This is actually the first time I've considered the interconnection of VNETS - but it occurred to me that each VNET appears to cater for only one Local Network, meaning that there is no site to multi-site connectivity. While it would be nice to have a dedicated VNET for RemoteApp - I'm not sure how a backend VNET could cater for that AND on-premises resources.