Tuesday, April 6, 2021

Transitive Routing and Site to Site VPN, Azure Firewall, VNET Peering, 4 VNETs

14 min to read.

Abstract

In earlier blog I talked about solving transitive routing problem in 3 VNETs. Recently I came across a situation where transitive routing was required across 4 layers.

A (On-premises DC) < site to site VPN> B (VNET with VPN GW) < peered to> C (Firewall VNET) < peered to> D (server app VNET).

Interested to know how to achieve transitive routing across 4 VNETs? Read on.

Problem Statement

Let us understand the problem better by using example. [Click to get better view]-



Requirements are as below -

1.      Contoso company has on-premises DC connected to Azure Landing Zone VNET using Site to Site VNET.

2.      Server Deployment should be done in separate VNET and all traffic should be monitored using Firewall

3.      The firewall must be placed in separate VNET for logical separation and more granular control.

4.      Communication between OnPremises DC server to Azure Server VNET must pass through S2S VPN, Firewall in both directions.

This is classic Transitive routing scenario in Azure, but a complex one. There are 4 networks and you need connectivity between first and fourth; without having them connecting directly.

Let us solve this one by one.

Solving on premises DC connectivity to Azure Landing Zone VNET

I don’t have any on premises site for demo. Therefore I created Azure VNET only and will be treating it as on premises site.

So we have 2 Azure VNETs across which we need connectivity. You can easily set it up using VNET to VNET connection or using VPN Gateway connection. However to replicate real world scenario we will create Site to Site VPN between On premises DC and Contoso Landing Zone Azure VNETs; using Azure VPN Gateway in each.

Connection between Server VNET to Firewall VNET

Server VNET needs to send data [ in our case we will just try RDP] to on premises DC VM. However they are not connected directly.

Also traffic to/ from server VNET has to be filtered through firewall. Therefore we created separate VNET for Server and firewall. I decided to use Azure firewall and the VNET is called as Transit VNET below.

As Server VNET just receive / send data to/ from Azure firewall; we need Standard VNET Peering between Server and Transit VNET.

Connection between Firewall VNET to Landing Zone VNET

Data from Server VNET VMs need to be sent to on premises. However it has to be passed from Azure firewall. Therefore we need Transit VNET to send data to on premises in reality.

So we want traffic from firewall VNET to reach to contoso on premises DC VNET using S2S VPN Gateways present in both VNETs.

For this we will need to setup VNET Peering with Remote Gateway option between Transit VNET and Landing Zone VNET. Only Standard VNET peering won’t work in this scenario.

Final Solution Architecture looks like below

[click to get better view].



Setting up Site to Site between Azure VNETs

We need to create two Local network gateway as shown in above diagram. You need to take care of below when you create S2S between Azure VNETs using Azure VPN Gateways.

1.      Create Contoso DC Local network gateway and assign public IP of Contoso DC VPN GW. Assign range of on premises DC private VNET.

2.      Create Contoso Zone Local Network Gateway and assign public IP of Contoso Zone VPN GW. Assign ranges of Server, Transit and Zone private VNET.

Refer below screenshots – [click to get better view]





Then to setup Site to Site IPSec tunnel follow the guide as describe here - Tutorial- Connect on-premises network to virtual network: Azure portal - Azure VPN Gateway | Microsoft Docs

Refer below screenshots – [click to get better view]





This completes the S2S connection between 2 Azure VNETs using Azure VPN Gateway.

Provision Azure Firewall and Add Network Rules

Create dedicated subnet for Azure Firewall in Transit VNET and then create Azure Firewall in Transit VNET.

We want RDP traffic from Server VNET to DC VNET and vice versa to allow through Azure Firewall. Therefore add below rules in Azure Firewall network rules. [click to get better view]



Setup VNET Peering between Server, Transit and Zone VNETs

First configure server VNET to Transit VNET peering as shown below. Here as both VNETs to dot have Azure VPN Gateway; so this will be standard VNET peering. [click to get better view]



Then configure Transit VNET to Zone VNET peering. Here Zone VNET has Azure VPN Gateway and we want traffic filtered from Transit VNET firewall to pass to on premises DC VNET over S2S.

Therefore use remote gateway setting in Transit VNET peer, and “Use this VNETs Gateway or Route server” setting in Zone VNET peer as shown. [click to get better view].



This step completes all the required peering setting as per architecture diagram.

Configure Azure Route Tables

From Server subnet we want traffic to go to Contoso DC and pass through Azure Firewall. Therefore we need to add below rules on server subnet –

1.      If destination is Contoso DC VNET then next hop is firewall IP

2.      If destination is Zone VNET then next hop is firewall IP

Then assign route table to server subnet as shown below. [click to get better view].



The traffic received on Contoso Zone GW and destined to server vnet should also be passed always to firewall. Therefore we need to add below rules on Zone Gateway Subnet route table –

1.      If destination is server VNET then net hop is firewall IP.

Then assign route table to Gateway subnet of Zone VNET. [click to get better view.]



This completes configuration of all Route tables.

Confirm the connectivity between Server and On Premises DC VNET

Login to Server VM using public IP. Then simply ping to on premises Dc VM. The ping should be successful as shown below. If we try to take RDP to On Premises DC VM over private IP from server VM; it should be successful as shown below. [click to get better view].



You can view the source address of server VM from event viewer as below – [click to get better view]



Similarly RDP from On Premises DC server to Server VM over private IP should also be successful.

Conclusion

Hope this article helped to design Transitive Routing across 4 VNETs.

Happy Peering!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.

Next Related Posts

Transitive routing across 3 VNETs using Ubuntu VM

Azure Virtual Machines – real world frequently asked questions – not easily answered.

Azure Migration frequently asked questions, not easily answered!

Azure VM disk encryption, what should be my approach!

Bypass onpremises firewall to RDP or SSH into Azure VM

Friday, March 19, 2021

Transitive Routing in Azure VNet Peering using Ubuntu VM IP Forwarder

8 min to read.

Abstract

Transitive routing requirement is common reality in every “Enterprise Grade” Azure Implementation!

Simplest way to connect two Azure VNet is to use Azure Vnet Peering. If I have 3 VNETs peered with each other; example A <> B <> C. I want Azure VM in A Vnet to talk to Azure VM in C Vnet then it wont work; because A and C VNet are not peered directly to each other; but through B Vnet.

Fact that VM in A vnet not able to reach VM in C Vnet is called as “Transitive Routing Problem”.

How do I solve it?

There are many solutions. Simplest way to solve transitive VNET peering problem would be, to create an “IP Forwarder using Azure Ubuntu VM” in B Vnet.

Let’s start!

Problem statement in detail




As you can see in above diagram I have 3 Azure Virtual Networks named as

1.      ContosoDC VNET

2.      UbuntuFwVNET  - you can also name it as Transit VNET.

3.      ContosoServer VNET

I have provisioned subnets as shown in the diagram. All VNETs are peered bi-directional as described below –

1.      Contoso Dc VNET < peered to> Transit VNET

2.      Contoso Server VNET < peered to> Transit VNET

Azure VNET Peering is bidirectional. Needless to say, if Contoso DC VNET peered to Transit VNET means; Transit VNET will also require peering to Contoso DC VNET to allow them communicate each other.

However, ContosoServer VNET and ContosoDC VNET are not peered with each other.

Note – None of these VNETs are having VNET Gateway or ExpressRoute Gateway in it. So when you peer make sure you choose None for gateway options as shown below [click to get better view].




I have 2 windows VMS and one Ubuntu VM [with Single NIC] in Transit VNET. One of the windows VM has public IP and rest of the two VMs do not have public IP.

Problem statement - I want to allow RDP from ContosoDCVM [10.11.0.4] to ContosoServer VM [10.10.0.4].

How to go to unknown destination - User Defined Routes - UDR

ContosoDC and Contoso Server VNET are not peered. This means both VNETs do not know each other’s address ranges.

When from an Azure VNET you want to send traffic to another unknown Azure VNET, you use Azure User Defined Route Tables aka UDR and provide the next hop to an appliance/ VM/ NVA/ Firewall/ Router/ or forwarder which will then take care of sending traffic to correct destination.

In our case the NVA is our ubuntu Azure VM. Therefore from both VNETs we need to send the traffic to Ubuntu VM IP. Then ubuntu VM will eventually DNAT [Destination NAT] the incoming traffic to its correct destination.

UDR on Contoso Server Subnet as below – [click to get better view]



UDR on Contoso DC Subnet as below – [click to get better view]





Configure Ubuntu as IP Forwarder

For this there are two settings. One on Network Interface of Ubuntu VM from Azure portal and one inside the OS of Ubuntu itself.

Go to NIC associated to Ubuntu VM and enable “IP Forwarding” as shown below [click to get better view] -  



Take SSH into Ubuntu VM and run below commands to enable the IP forwarding inside OS.

$ sudo vim /etc/sysctl.conf

Uncomment the below line – [remove #] and then press Esc and type :wq to save the file.

net.ipv4.ip_forward=1

Run below command to confirm if the change is correct – 

$ sudo sysctl -p

This completes the configuration of IP forwarding for Ubuntu VM.

NAT the incoming traffic

NATing is of two types.

Source NAT – SNAT – to be used when you want to change the sender’s address.

Destination NAT – DNAT – to be used when you want to change the destination address.

Example, Web application is hosted on behind the firewall. Firewall VM has public IP and actual application runs on web server which has private IP. In this case, incoming web request reaches to public IP of firewall and get forwarded to web server private IP. This is translation from public IP to private IP. This is DNAT.

In our case we need to perform DNAT as destination is not known to each of the VNET. Only Transit VNET knows both VNETs. Also in our case DNAT will be for private IP to private IP, as there is no public IP in picture here.

DNAT can be achieved using iptables in PREROUTING and POSTROUTING chaining. To know more refer this awesome link - https://www.karlrupp.net/en/computer/nat_tutorial.

In our case we need below DNAT chaining –

1.      PREROUTING - If source is 10.11.0.4 then DNAT to 10.10.0.4:3389

2.      PREROUTING - If source is 10.10.0.4 then DNAT to 10.11.0.4:3389

3.      POSTROUTING - For all DNAT, use IP address of Ubuntu VM as source

The respective commands are as follows – run it on Ubuntu VM –

$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp -s 10.11.0.4 --dport 3389 -j DNAT --to-destination 10.10.0.4:3389

$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp -s 10.10.0.4 --dport 3389 -j DNAT --to-destination 10.11.0.4:3389

$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

These iptables configuration are not persistent over reboots. So we need to use “iptables-persistent” module to make it happen.

Run below commands – 

$ sudo apt-get update

$ sudo apt install iptables-persistent

On running above command you will have to enter “Yes” twice. This completes the installation of iptables-persistent module.

Then read all iptables configuration we perform and pipe [or copy paste] to rules files. Then add this rules files path in rc.local which eventually will make our iptables configuration persistent over reboot of ubuntu machine. Run below commands – 

$ sudo iptables-save > /etc/iptables/rules.v4

$ sudo vim /etc/rc.local

Add below line in /etc/rc.local file and then save the file by pressing Esc -> :wq.

/sbin/iptables-restore < /etc/iptables/rules.v4

Reboot the machine by typing below command – 

$ sudo reboot

This completes the configuration of iptables and NAT on ubuntu machine. 

Confirm the connectivity

Login to Contoso server VM over public IP. You can leverage Azure Bastion, Jump VM, or any other option for this. After login lets confirm if the traffic is flowing to ContosoDc VM through Ubuntu VM. For this I ran tracert command and output shows that the traffic does flow through ubuntu VM as shown below – [click to get better view] –



Similarly I could see return traffic from ContosoDC VM to ContosoServer VM was flowing through ubuntu VM – [click to get better view]



You should be able to take RDP between the VMs. Post RDP I checked the source in event viewer of both windows VM and I could see the source IP as ubuntu IP from which DNAT occurs.

Source IP of RDP can be viewed from below path in Event viewer - Event Viewer > Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational

Screenshot of ContosoDc machines – [click to get better view]



This concludes how an Azure Ubuntu VM can be configured as “IP Forwarder” to achieve Transitive routing in Azure VNET Peering.

What are the other ways to achieve transitive routing in Azure VNet peering?

What we did with Ubuntu is, we built IP forwarding out of it from scratch. This is readily available with leading firewall and routing devices such as PaloAlto, CheckPoint, Barracuda etc. The only difference is those devices will come with licenses cost. Ubuntu VM we built does not incur any licenses cost.

How to achieve Transitive routing in peered VNet using Azure Firewall?

This possible using Azure Firewall.

Deploy Azure firewall in Transit VNET. You just need to allow traffic from ContosoDC to Contoso Server VNET and vice versa as a Firewall Network rule. Configure the UDR on both VNETs with next hop to Firewall private IP and you are done.

Conclusion

Hope this article helped to design IP forwarder using simple Azure Ubuntu VM to solve your Transitive Routing needs.

Happy Peering!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.

Next Related Posts

Transitive Routing with 4 VNETs and Azure Firewall

Azure Virtual Machines – real world frequently asked questions – not easily answered.

Azure Migration frequently asked questions, not easily answered!

Azure VM disk encryption, what should be my approach!

Bypass onpremises firewall to RDP or SSH into Azure VM 

Thursday, November 26, 2020

Can Azure WVD inbound traffic pass through my firewall?

11 min to read.

Abstract

Corona Virus is giving birth to new technologies and new way of working!

Remote work has been in the center of technology discussion in all organizations. Azure Windows Virtual Desktop has been on leading front to enable organization to enable remote working.

When we talk to security teams about remote working using Azure WVD; every organization wants remote working incoming traffic to flow through their perimeter firewall deployed on Azure. This is obvious because all incoming traffic will be coming from internet and getting into Azure WVD environment of customer.

This is fair ask and every organizations security team wants to monitor all incoming traffic from internet.

So obvious question that comes to Azure Architects is -

Can you please make sure that all incoming/ inbound/ ingress traffic from client devices to Azure WVD flows through our Firewall devices hosted on Azure?

The answer is Yes.

However in my opinion the question is incorrect!

How? Let’s talk about it.

Azure WVD and Reverse Connect

See, I am not blaming security team for asking incorrect question; it is more of unawareness of how Azure WVD connection work. It is more of responsibility of Azure Architects working within an organization to make Security teams aware of how Azure WVD traffic flow and connections work.

Reverse connect is a unique technology offered only on Azure WVD. Reverse connect technology means your WVD host VM doesn’t need any inbound ports to be opened. Even the default RDP port, TCP/3389, doesn’t have to be open. Instead, an agent creates an outbound connection using TCP/443 into the Windows Virtual Desktop management service.

Most of the time we misunderstand the Azure WVD Reverse Connect as shown in the Red color line in below diagram [click to get better view] - 

.


As per general understanding I have observed below understanding of the traffic flow –

1.      Client device connects to WVD common URL either from browser or from app installed on client machine. This traffic flows over internet.

2.      The request from client machine is forwarded to WVD management control plane.

3.      The broker in WVD management service initiates connection to actual WVD host. This traffic also flows over internet.

In above traffic flow the traffic is reaching to WVD host VM directly without passing through the firewall device.

This is not correct understanding.

Reverse connect means Broker will not initiate the traffic to WVD host VM rather WVD host VM will initiate the connection to Broker of WVD management service.

This means the traffic to connect to WVD host is OUTBOUND/ EGRESS/ OUTGOING traffic from WVD host and not INCOMING/ INBOUND/ INGRESS traffic to WVD host VM.

Passing WVD host connection traffic through Firewall

Now that we understand about WVD host making outbound call for honoring connection requests; we just need to have this traffic going through Firewall device. The firewall device can be either NVA or Azure Firewall.

To pass this outbound traffic initiated from WVD host VM through firewall we will need to add UDR – User Defined Route on WVD Subnet. The routes will be as follows –

-        If destination is on-premises then next hop is Gateway

-        If destination is 0.0.0.0/0 then next hop is firewall device private IP

The connection traffic will be falling under the category of 0.0.0.0/0. This way connection traffic initiated from WVD host VM will also pass through Firewall device.

This way security teams requirements will also be satisfied as now they actually can inspect outgoing traffic in firewall from WVD Subnet.

Refer to below diagram – [click to get better view]

 



The correct network traffic flow will be as follows shown in green in diagram –

1.      Client device connects to WVD common URL either from browser or from app installed on client machine. This traffic flows over internet.

2.      The request from client machine is forwarded to WVD management control plane.

3.      The WVD host VM has an agent running on top of it. This agent then initiates the traffic to WVD management service as an OUTBOUND connection.

4.      WVD management service traffic falls under category of 0.0.0.0/0 and hence the traffic is forwarded to firewall device.

5.      From firewall device the traffic goes to WVD management service.

6.      After successful authentication from user the actual connectivity is established between client device and WVD host VM.

All of this communication happens over 443 and there is no requirement of opening 3389 default RDP port anywhere. This is the beauty of  WVD reverse connect.

Wrapping up

Remember, there is no Inbound traffic in case of connecting to WVD host VM.

Therefore correct question to security teams –

Can you allow WVD connection traffic to pass through my firewall device?

Answer - Yes using UDR on WVD subnet; we can pass WVD connection traffic to flow from firewall device.

Conclusion

Hope this article helped to design your WVD deployment architecture in right way and gave better understanding of WVD traffic flow.

Happy Remote working!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.

Next Related Posts

Azure Virtual Machines – real world frequently asked questions – not easily answered.

Start stop multiple Azure VMs on schedule and save cost!

Export Azure VMs to CSV!

Azure Migration frequently asked questions, not easily answered!

Azure VM disk encryption, what should be my approach!

Bypass onpremises firewall to RDP or SSH into Azure VM

Tuesday, April 28, 2020

Run Android emulator and Android Studio on Azure VM using Hyper V

14 min to read.

Abstract

Due to Corona outbreak, times are hard! Please take care everyone! I wish good health for all! Stay safe!

There is another outbreak I am seeing – Making Development environment available on Azure to enable Work from home. Almost in every customer call I hear about requirement to enable Development Environment on Azure and accessing it from Home laptop/ PC and continue the business.

In the era of “Mobile first” almost every big enterprise, every Small and Medium Business (SMB), every Start up company have mobile development teams. They use variety of tools and one of the important IDE used for Mobile development is “Android Studio”.

Installing and running Android studio is smooth; however Android emulator installation fails on Azure VM. It is not straight forward. In this blog we will see “how to enable Android emulator with Android Studio on Azure VM”.

Let’s go!

Concept - Android Emulator and VM Acceleration

Without a virtualization technology and VM acceleration, the Android emulator must translate the machine code from the VM block by block to conform to the architecture of the host computer. This process can be quite slow. 

With a hypervisor, the VM and the architecture of the computer running emulator match, so the emulator can run code directly on the processor using the hypervisor. This improvement drastically increases both the speed and performance of the android emulator.

This concept is well suited for hardware. For example, if you have laptop then Android emulator can work like a charm. Because the required hardware for VM acceleration is provided by underlying laptop on which you are running Android Studio and hypervisor for emulator runs on laptop hardware.

Android Emulator and Intel HAXM

Android emulator is default based on Intel Hardware Accelerated Execution manager [HAXM]. This is Virtualization technology used behind the scene by Android studio to run the android emulator. HAXM is installed as a part of installation process of Android Studio as well.

So on Azure VM where we plan to run the Android simulator, Intel HAXM should be installed and present.
At the same time Intel HAXM and Hyper V are mutually exclusive. Means, if you have Hyper V enabled then HAXM can’t be installed and vice versa.

Installation of HAXM on Azure VM is not a problem. The VM series is a problem. When you say I want to install the HAXM; Hyper V should be disabled. Most of the VM series today have Hyper V “some way” enabled or not supported.

Remember Azure VM itself is a VM. Means it is based on Hyper V behind the scene already. Now on top of this VM you want to install another Hypervisor – either HAXM or Hyper V. The only series that supports the Hyper V on Azure VM itself is Hyperthreaded VMs – Dsv3 and Esv3 series or Dv3 and Ev3 series.

This Azure VM series support nested virtualization; because it supports running Hyper V on top of it or running any other hypervisor on top of it. Therefore installation of HAXM on Azure VM will succeed only on these Azure VMs and other will fail.

Now even if we install HAXM successfully on Azure VM and then install Android Studio with emulator successfully; the emulator will not work. I have experienced many errors as described below -

“error while loading state for instance 0x0 of device 'goldfish_pipe'”.

“Unfortunately, the Android emulator can’t support virtual machine acceleration from within a virtual machine.”

Android Emulator and WHPX

Microsoft Visual Studio has Android Emulator. It uses WHPX technology behind the scene. However it works on hardware. Means it can run well on your laptop but not on Azure VM. I could not start Android Emulator on Azure VM. When I attach the Visual Studio Android Emulator to Android Studio; it fails with many errors.
So what is the solution?

Solution and Architecture

Well, the solution provided will not help to run the latest version of Android emulator. However you will be able to make the Android Emulator work on Azure VM with “Older version”.

For this we will leverage “VS Emulator for Android” which is earlier version of Android Emulator Microsoft had released prior to current version of “hardware acceleration” based Android emulator.

So overall solution looks as follow – [click to get better view].



As a part of the solution make sure you provision VM with v3 series. I have selected Ds4v3 VM on Azure portal and provisioned it. By default allow the internet access to this VM so that we can download required software. As per the diagram I have attached public IP to my VM. So take RDP over public IP.

After RDP, install the software in the order mentioned below.

Visual Studio Emulator for Android – Life saver!

I have selected below version [click to get better view] of Windows 10 for provisioning VM on Azure. Also I have selected Ds4v3 series and Gen1 for provisioning. Go ahead and provision Azure VM.



Install Hyper V

Login to your VM and configure Hyper V on top of it. Open Run window -> type “appwiz.cpl” -> Click on “Turn windows feature on or off” -> Select all options against Hyper V option -> Select option “Windows Hypervisor platform”. After successful installation restart VM. Refer below [click to get better view].



Install Java

VS Emulator for Android requires Java. Therefore install using the link - https://www.java.com/download/.
Restart the machine.

Install Visual Studio Emulator for Android

Go to this page - https://visualstudio.microsoft.com/vs/msft-android-emulator/. Install VS emulator for Android. Remember we don’t have to install the complete Visual Studio here. The Visual Studio based Android emulator is based on Hardware acceleration and it will not work on Azure VM. At least I could not make it work after lot of attempts.

Successful installation screen shown below. It should also appear in start menu. [click to get better view].

After installation restart the Azure VM.



Install Android Studio

Install Android Studio from the link - https://developer.android.com/studio#downloads. Current version as of today is Android Studio 3.6.3. Install with default selected options. After successful installation you will see an option “start android studio”. Select this option and click finish as shown [click to get better view].



This launches the Android Studio and further starts configuration of Android Emulator. Continue with standard configuration with default options selected. You will see that HAXM installation failed. This is expected behavior as Hyper V is already enabled; HAXM is bound to fail. You will get screenshot as follows [click to get better view] –



This completes the installation of all required software. Restart the machine.

Integrating Android Studio to use Visual Studio Emulator for Android

The default path of Android SDK for me is - C:\Users\kunal\AppData\Local\Android\Sdk. This is default path.

We need to set a specific registry key to tell Visual Studio Emulator for Android where the Android Sdk is located. To set the needed registry key, run the script below in PowerShell on the Azure VM. If you have installed it on different path then change the below path in script accordingly.

$androidSdkPath = Resolve-Path $(Join-Path "$($env:APPDATA)" "../Local/Android/Sdk")

$registryKeyPath = "HKLM:Software\WOW6432NODE\Android Sdk Tools"
New-Item -Path $registryKeyPath
New-ItemProperty -Path $registryKeyPath -Name Path -PropertyType String -Value $androidSdkPath


Successful execution of the script will have below view [click to get better view].



Running Android Studio with VS Emulator for Android

First open Visual Studio Emulator for Android. On the launch screen you will see all version available in this emulator. You will see the last version that were available on this was API 23 Marshmallow. Refer below screenshot [click to get better view].



From above screen I downloaded the red marked device for emulator. When you click on Green checkmark then Device emulator starts as shown below [click to get better view].



Now open Android Studio. Click on “Start a new Android Project” on start screen. Then Select the Project Template as Basic Activity. Click Next. On “Configure your project” screen I selected Java as Language and kept rest of the setting as is. Click Finish. The creation of new project will take few mins. Final screen will be visible as shown. As you can see, VS Emulator is also visible on the below diagram. This means Android Studio has picked up VS Emulator for Android [click to get better view].



Go ahead and click on Run to deploy your test application on this emulator.

Post deployment you will see your application running on Visual Studio Emulator for Android as shown below [click to get better view].



Follow general security best practices when you take RDP over internet to this VM. Like whitelisting incoming IP in NSG etc.

Disclaimer

Visual Studio emulator for android is obsolete version and has last version of android available as API 23 – Android 6.0 - Marshmallow. However currently Android is running with version API 29 – Android 10.0 - Q.
I know we are not running on latest version however this workaround unblocks us in current Covid-19 situation.

Also, on top of this page - https://visualstudio.microsoft.com/vs/msft-msandroid-emulator/, it explains you that current version of Android Emulator uses hardware acceleration. VS Emulator for Android is older version of it and not recommended. 

However I chose this solution to my customers as of now; as this unblocks the customer immediately with the power of Azure cloud.

Also, right now my customer was not able to perform any android specific development task due to Corona virus situation. So even if older version, at least customer was able to continue the business and that was more important.

I repeat, the above approach of using older version of VS emulator is obsolete. For best experience you should switch to Hardware based emulator either using HAXM or WHPX. The above stated approach is a workaround for now. May be in future Microsoft Azure may release “absolutely non restricted Hyper V” supporting VMs and it may work.

Please note, this recommendation is my personal recommendation and in no way it represents the company I work for.

Bonus Tip

You can very well use this approach with Azure Windows Virtual Desktop [WVD]. Plus on top of it if you want to test your APK by device connection to USB; then you can enable local laptop USB while you take RDP to WVD and make it work.

Conclusion

Hope this article helped you to get started on Android Studio and Android emulator with Azure VM quickly. Let me know your views in comments section below to improve and what are your thoughts on this approach.
Happy emulating!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.

Next Related Posts