How to link Azure RemoteApp to an existing VNET

How to link Azure RemoteApp to an existing VNET

Rate This
  • Comments 9

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)

10.1.0.1

Backend VNET Address Space

10.1.0.0/19

RemoteApp VNET Address Space

10.2.0.0/19

Gateway IP for Backend VNET

 

Shared Key

 

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

Figure0

b. Choose a name and a location for your backend VNET.

Figure1

c. Enter your DNS server’s IP address.

Figure2

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.

Figure3

2. Prepare Backend VNET for VPN.

a. NEW -> NETWORK SERVICES -> VIRTUAL NETWORK -> ADD LOCAL NETWORK

Figure4

b. At this point you need to feed the local network a random VPN device IP as our RemoteApp VNET does not exist yet.

Figure5

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.

Figure6

d. After the local network has finished creating, switch back to your recently created backend VNET.

Click the CONFIGURE tab.

Figure7

Click the Connect to the local network checkbox and choose the local network you just created from the LOCAL NETWORK dropdown.

Figure8

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.

Figure9

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.

Figure10

f. After gateway creation had finished your VNET should resemble what is below.

Figure11

g. At this step you will want to update your table with the Gateway IP address.

DNS IP(must be in backend)

10.1.0.1

Backend VNET Address Space

10.1.0.0/19

RemoteApp VNET Address Space

10.2.0.0/19

Gateway IP for Backend VNET

23.100.42.45

Shared Key

 

Gateway IP for RemoteApp VNET

 

3. Create RemoteApp VNET

a. NEW -> APP SERVICES -> REMOTEAPP -> CREATE WITH VPN

Figure12

Should look like this

Figure13

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

Figure14

c. Place the RemoteApp VNET in a region close to your backend VNET for best performance.

Figure15

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.

Figure16

e. Next enter your DNS Servers IP address and the VPN IP address that we generated earlier in our Gateway creation (23.100.42.45 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.

Figure17

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.

Figure18

Figure19

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

10.1.0.1

Backend VNET Address Space

10.1.0.0/19

RemoteApp VNET Address Space

10.2.0.0/19

Gateway IP for Backend VNET

23.100.42.45

Shared Key

WhFVekpMcpgrBmxuX1cEHUYLtMKwMmew

Gateway IP for RemoteApp VNET

191.239.33.244

4. VNET to VNET Connectivity

a. NETWORKS -> LOCAL NETWORKS

Figure20

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.

Figure21

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.

Figure22

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.

Figure23

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.

Figure24

f. Your RemoteApp VNET should switch to be in a ready state about 5-10 minutes after you see that the VNETs are connected.

Figure25

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.

Leave a Comment
  • Please add 1 and 1 and type the answer here:
  • Post
  • thank you

  • 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.

  • @Chris,

    Sorry for the late reply, but I have setup the VPN with static routing between a RemoteApp VNet and an on-premises device that supports static routing (TMG in my case). I had to use this as a guide to configure TMG and it worked for me:

    blog.kloud.com.au/.../windows-azure-virtual-network-vpn-with-tmg-2010

    No guarantees.

    Jim

  • Very useful and complete guide. Thanks. I had to do one more thing since I have multiple subscriptions and the subscription I used was not the default. I used Select-Subscription to set the correct subscription I used to create all VNET stuff in.

  • Hi, great article!

    I have used this to setup a new VLAN and local RemoteApp lan in Azure. As I did not have yet a vm available in my vlan that has Active Directory installed, I added a new server to this VLAN, and added the role for AD (incl. dns etc).

    Also I gave this server a fixed ip adress of 10.1.0.4, for enabling DNS.

    Then I configured RemoteApp to use my new Active directory, only when the provisioning started, I get the error 'Could not provision the RemoteApp collection. Error: DNS server could not be reached'.

    After this error, I changed the DNS server in the VLAN to the ip adress of my AD VM 10.1.0.4 (which was first set to 10.1.0.1), and tried again.

    Waiting now for it to work.. but I have some questions, hopefully you can help me with this:

    - On my Domain controller VM 10.1.0.4, I now cannot access the internet, how to configure this when this server is also the DNS server? (do I have to add a DNS entry in the VLAN settings?)

    - I changed the Ip on the Domain controller to fixed 10.1.0.4, which is also the start range of the VLAN subnet, does this give issues when other servers are added to this VLAN? (when receiving DHCP entry?)

    - Does the RemoteAppLocal need to have a DHCP server or something for scaling the servers?

    Thanks!! If you have suggestions, please let me know!

  • Is it possible to do this if you're using the Azure-provided DNS server? I really don't want to spin up another VM just to install AD.

  • Hi Jeroen and Dan, good questions!  Here are my responses to each of them:

    - On my Domain controller VM 10.1.0.4, I now cannot access the internet, how to configure this when this server is also the DNS server? (do I have to add a DNS entry in the VLAN settings?)

    Based on what you’ve posted, I’m not sure why you can’t access the internet from your DNS server.  I’m no DNS expert but I’m guessing there are several things that can cause this.  Maybe check what you have configured for Forward Lookup Zones?  If this is important, I’d suggest opening an Azure support ticket to help you troubleshoot.

    - I changed the Ip on the Domain controller to fixed 10.1.0.4, which is also the start range of the VLAN subnet, does this give issues when other servers are added to this VLAN? (when receiving DHCP entry?)

    No, new machines added to the VNET should just pick up the next available IP address.

    - Does the RemoteAppLocal need to have a DHCP server or something for scaling the servers?

    No, the RemoteApp service handles IP address assignment for VMs it creates.

    - Is it possible to do this if you're using the Azure-provided DNS server? I really don't want to spin up another VM just to install AD.

    Currently no, though you’re not the only one to highlight this pain point, so we’re actively investigating a solution for you.

    Hope this helps,

    Tristan

  • Hi Tristan,

    One more question...

    Why does the image below 3e show DNS SERVERS IP ADDRESS as 10.0.0.1? All other references to the DNS server show the IP address as 10.1.0.1.

  • This is more related to the VNET-side, but how do you create VM in the address space designated for the DNS server? When you create a new VM you can select only one of the 2 subnets.

Page 1 of 1 (9 items)