Azure Firewall with Static Outbound Public IP – Azure NAT Gateway

12 min to read.

Abstract

Below conversation may come as a surprise for some organizations when they onboard on Azure Firewall – [Click on image to get better view]

Azure Firewall randomly selects attached public IPs for outbound SNAT connections.

Many times for outbound connections, organizations prefer to use static public IP for Outbound SNAT connections. This helps a lot in whitelisting at organization customer’s / partner’s end. As of today Azure Firewall do not offer this capability.

This article talks about; how can you make sure that traffic leaving Azure Firewall uses a static public outbound IP addresses or range of static public IP addresses.

The solution proposed below is being used in many large enterprises today successfully, for providing static outbound IP to Azure Firewall.

Let’s go!

Understanding inbound and outbound connections

In below diagram I have one Azure VNET in which I have deployed one windows server and Azure Firewall instance in dedicated subnet. Let us quickly understand what is inbound and outbound traffic flow.

The Azure VM do not have any public IP assigned to it. If I host a sample application on top of this Azure VM then public facing endpoint is public IP of Azure Firewall.

Inbound means traffic originating from internet and reaching to Azure VM through DNAT operation of Azure Firewall. Refer below diagram – [click on image to get better view].

Note – Remember, for the inbound connection there will be response sent. This is response traffic and not outbound traffic.

Outbound means traffic generated within Azure environment and going out to internet. Refer below diagram – [click on image to get better view].

Problem Statement

No Outbound Static IP

Now that inbound and outbound traffic is clear; in above diagram Partner DC may ask for public IP of your Azure environment to whitelist in their firewalls. So in that case we will need static public IP/ range of public Ips assigned to firewall.

This way outbound traffic generated with Azure [in our case inside Azure VM] to partner DC will be SNAT to static public IP.

However as stated above; Azure Firewall randomly picks up any public IP assigned to it for outbound SNAT. This proposes challenges to customers.

Limited SNAT ports

Another important point to consider is about SNAT ports. When traffic goes out from firewall, a port will be used to send the traffic outbound. These number of ports are always per public IP assigned to Azure Firewall. Azure Firewall offers 2048 ports per public IP assigned. This might be a lower number based on application nature.

Whenever one outbound connection is made, one port will used from Azure Firewall. The engaged port is not released until connection operation is completed. At the same time if Azure Firewall needs to make another outbound connection then another port will be used.

This means, at any given point, one instance of Azure Firewall service with one public IP attached, can make maximum 2048 outbound concurrent connections.

Azure Firewall support max 250 public Ips. So total SNAT ports available on Azure Firewall – 250*2048 = 512,000.

However, 250 public IP is still a big number. You do not attach so many public Ips to Firewall instance out of the blue. You generally attach per application. Bringing 250 applications behind single Azure Firewall instance may not be possible right away when you start Azure journey.

At the same time; your single application running behind Azure firewall may easily need concurrent a million outbound connections. Example, WebSocket based chat application, mobile app communication using websockets.

Therefore we need a way by which we can scale SNAT ports as well for outbound connections passing through Azure Firewall.

Verifying Random IP Behavior

I have below construct in my Azure Subscription. [Click on the image to get better view] –

1.      Created VNET with 3 subnets – Firewall Subnet, Web VM subnet, Jump VM Subnet

2.      Attached two public Ips to Azure Firewall.

3.      Created Web VM in Web Layer and did NOT attach any public IP.

4.      Create Route Table with below routes and attached to web layer subnet

a.      If destination is Jump Layer subnet – next hop VNET

b.      If destination is internet [0.0.0.0/0] – next hop AzureFirewall IP.

5.      Created Jump VM WITH Public IP; just to take RDP to web VM over its private ip.

Here are the screenshots of Azure Firewall IP configurations and UDR on Web Layer Subnet. [click to get better view].

I am going to add ifconfig.me domain inside Azure firewall to allow the outbound traffic. Therefore we need to add DNS settings on Azure Firewall. Below is the screenshot to add the same – [click to get better view].

We will be using ifconfig.me URL to get the IP. Therefore allow the same in Azure Firewall as shown below using application rules. [click to get better view].

Now when I run command Curl ifconfig.me/ip from putty of Web VM; we see the firewall IP as an output. This means because of UDR attached to web layer, internet traffic initiated from web vm is passing through Azure Firewall. Azure Firewall then sending to internet by SNAT [Source NAT] to its own one of the public IP.

From below screenshot you can clearly see that any random IP out of two public Ips attached 

to Azure Firewall, is being used while outbound traffic is SNAT from Azure Firewall. 

[click to get better view]. 

From above screenshot it is visible that out of the two public Ips random IP is being chosen for outbound access.

Here is the Deal…NAT Gateway!

Microsoft Azure releases Virtual Network NAT service that simplifies the outbound-only internet connectivity for virtual networks. When configured on a subnet, all outbound connectivity uses your specified static public IP addresses.

Many times this service is also referred to as NAT Gateway.

Per public IP attached to NAT gateway we get 64,000 outbound SNAT ports. One NAT gateway can have 16 public IP addresses attached.

So total outbound SNAT ports available with a NAT gateway = 16 * 64,000 = 1,024,000.

So NAT Gateway is our solution to get Static Public IP for outbound traffic flowing through Azure Firewall.

Create NAT gateway and associate to subnet of Azure Firewall. Assign a public IP to NAT gateway. So as shown in the below diagram, even if the Azure Firewall has 2 public IP addresses; traffic originating from Web VM always take NAT Gateway associated public IP as outbound IP. [click to get better view].

Create NAT GW and associate to AzureFirewallSubnet using below sample powershell commands. Make sure you replace Resource groups name, VNET Name and location as appropriate.

# Create public IP addresses

New-AzPublicIpAddress -Name public-ip-1 -ResourceGroupName AzFwStaticIPRG -Sku Standard -AllocationMethod Static -Location 'Central India'

# Create NAT gateway

$PublicIPAddress1 = Get-AzPublicIpAddress -Name public-ip-1 -ResourceGroupName AzFwStaticIPRG

New-AzNatGateway -Name firewall-nat -ResourceGroupName AzFwStaticIPRG -PublicIpAddress $PublicIPAddress1 -Location 'Central India' -Sku Standard

# Associate NAT gateway to subnet

$virtualNetwork = Get-AzVirtualNetwork -Name MyVNET -ResourceGroupName AzFwStaticIPRG

$natGateway = Get-AzNatGateway -Name firewall-nat -ResourceGroupName AzFwStaticIPRG

$firewallSubnet = $virtualNetwork.subnets | Where-Object -Property Name -eq AzureFirewallSubnet

$firewallSubnet.NatGateway = $natGateway

$virtualNetwork | Set-AzVirtualNetwork

 The Azure NAT Gateway I created has public IP address 52.x.x.20 and is visible on Azure portal as below – [click to get better view].

Similarly it is associated to AzureFirewallSubnet as shown below – [click to get better view].

Verifying Static Outbound IP Address

Logged in to webvm using SSH and ran curl ifconfig.me command. We can see that it is showing Nat Gateway IP. Using NAT Gateway, for outbound traffic passing through Azure Firewall NEVER selected random IP from Azure firewall. [click to get better view].

Conclusion

Hope this article helped to overcome behavior of random public IP selection of Azure Firewall for outbound traffic. NAT Gateway is fully managed service and helps to configure static public outbound IP for outbound traffic passing through Azure Firewall.

Happy Static IPs!

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

Proven Azure Architecture Patterns using PaloAlto NGFW and F5 DDoS and WAF

4 VNETs and transitive Routing using Azure firewall

Azure Virtual Machines – real world 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 

PaloAlto NGFW, F5 WAF and DDoS - Proven Azure Architecture Patterns

14 min to read.

Abstract

I have been part of many Azure Landing Zone implementations in last 1.5 years. Many organizations are already invested on below security devices –

1.      F5 WAF – Web Application Firewall

2.      F5 DDoS – Distributed Denial of Service

3.      PaloAlto NGFW – Next-Generation Firewalls

Enterprises have inclination to use same devices on Azure as well. Not only because they are invested in licenses costs but also on skillset cost. There are dedicated [paid] teams managing these devices and logging, monitoring, SOC, incident management, dashboards everything is already streamlined for them.

This article talks about Azure Architecture patterns I have seen across many organizations Azure Deployment using F5 WAF, DDoS and PaloAlto NGFW.

Note - Below I am considering incoming traffic from internet and outgoing to internet. I am not talking about Azure-OnPremises connectivity scenario in below architecture patterns.

Also recommendations as per my experience; deploy the security devices in dedicated VNET and configure all applications in separate VNET [Hub-Spoke!].

Azure Architecture Pattern 1

Refer to first pattern on deploying F5, PaloAlto devices in combination on Azure – [Click on image to get better view].

Pattern 1 Description

1.      The traffic from internet lands on public IP attached to External Standard Load Balancer [Layer 4] of Azure in front of F5 DDoS VMs.

2.      On External Azure Standard load balancer you can configure inbound public Ips. These public Ips can be added as per number of applications sitting behind your internet DMZ.

3.      DDoS Azure VMs are configured as Active-Passive or Active-Standby. At any given point only single Azure VM of F5 DDoS is serving the incoming requests from internet.

4.      PaloAlto NGFW VM-Series Azure VMs are configured as active-passive. It has an Azure Standard internal load balancer in front of it for load balancing and HA achievement. For monitoring purpose it is required to know incoming source IP at firewall; therefore we did not perform SNAT on DDoS. However at PaloAlto VM-Series firewall on Azure we can perform SNAT [if need be].

5.      F5 WAF VMs are present behind the PaloAlto NGFW. F5 WAF is also configured in Active-Active configuration. It has an internal load balancer in front of it for load balancing and HA achievement.

6.      F5 WAF machines do not have any public IP assigned.

Where do we perform SSL Offload?

To inspect incoming traffic; SSL offload is mandatory. Without SSL Offload packet can’t be inspected/ verified if it is valid traffic or malicious traffic. Therefore in above Azure Architecture pattern we should perform SSL Offload on F5 DDoS VMs. Post which you can inspect traffic on PaloAlto NGFW and F5 WAF.

What if I want to achieve end to end SSL on incoming traffic?

Perform SSL Offload on F5 DDoS Azure VMs. Then let traffic be inspected on F5 DDoS, PaloAlto NGFW and F5 WAF Azure VMs. On F5 WAF itself post inspection you re-configure the leaving traffic with new SSL certificate. So after F5 WAF when traffic goes to application VMs then it will be accessed over internal private IP communication; over HTTPS. This is end to end SSL.

How my outbound traffic “generated within my Azure environment” will flow?

In above diagram we have configured/ assigned public IP directly to one of the Azure PaloAlto VM. So traffic initiated from Application VMs directly goes to Azure PaloAlto VM and then it goes out to internet. In this traffic flow, F5 WAF and F5 DDoS Azure VMs do not come in to picture.

Make sure you attach separate public IP to one of NIC of each PaloAlto Azure VMs.

In case you want to ask 3^rd party company to whitelist your outgoing IP in their firewall; then both Ips of firewall will be required to whitelisted.

Note - If you fear of exhausting SNAT ports for Azure PaloAlto VM then you can also configure Azure NAT gateway in same subnet of PaloAlto NGFW external/ internet interface and use it for all outbound traffic. I have not tried this but should be pretty straight forward.

Azure Architecture Pattern 2

Many times customers prefer to use separate public Ips for inbound and outbound traffic. Separate outbound traffic public IP helps in whitelisting at their customers end. Example, WoodGrove org has api which will be called from Azure environment of Contoso company. So WoodGroove will ask Contoso to provide public IP range from which the api will be called. In this case Contoso will share the public IP to WoodGroove, specifically attached for outbound traffic “generated within Azure”.

In above pattern #1, we have public IP attached at the F5 DDoS Azure LB and also to the PaloAlto NGFW VM-Series. Sometimes customer do not want any public to be attached other than entry point. This can be addressed using below pattern. [Click on image to get better view].

Pattern 2 Description

1.      The traffic from internet lands on public IP attached to External Azure Standard Load Balancer [Layer 4] of Azure in front of F5 DDoS Azure VMs.

2.      On External Azure Standard load balancer you can configure inbound public Ips. These public Ips can be added as per number of applications sitting behind your internet DMZ.

3.      DDoS Azure VMs are configured as Active-Passive or Active-Standby. At any given point only single Azure VM of F5 DDoS is serving the incoming requests from internet.

4.      PaloAlto NGFW Azure VMs are configured as active-passive. It has an Azure Standard internal load balancer in front of it for load balancing and HA achievement.

5.      F5 WAF VMs are present behind the PaloAlto NGFW. F5 WAF is also configured in Active-Active / Active-passive configuration. It has an internal load balancer in front of it for load balancing and HA achievement.

6.      F5 WAF and PaloAlto NGFW VMs do not have any public IP assigned.

7.      Standard Azure load balancer attached in front of F5 DDoS also has outbound rules configured. To know more refer - https://docs.microsoft.com/en-us/azure/load-balancer/outbound-rules#scale.

8.      SSL Offload still happens at F5 DDoS Azure VMs.

9.      There is no SNAT performed for incoming traffic at DDoS therefore source IP is visible in PaloAlto NGFW Azure VMs.

 

How my outbound traffic “generated within my Azure environment” will flow?

In above diagram we have configured/ assigned public IP to External Azure Standard Load Balancer; present in front of F5 DDoS Azure VMs. Therefore we will need to configure UDR [Azure Route Tables] to make outbound traffic flow in below sequence –

App VM -> F5 WAF -> PaloAlto NGFW -> F5 DDoS -> Azure Standard LB -> Internet

In this case, outbound traffic flowing through F5 WAF and DDoS do not add any value. However as customer requirement is not to allow any public IP other than entry point; we will have to make traffic flow through each of the device. Here F5 WAF and DDoS will act only as pass through for traffic and adding extra hops.

Azure Architecture Pattern 3

When I implemented Azure Landing Zones at financial organizations many of them asked a variation in above patterns with Proxy deployment on Azure for Outbound traffic. So for outbound traffic below can be another architecture pattern where traffic flows as - >

App VMs-> Proxy VMs -> PaloAlto NGFW VMs -> Internet.

Same approach can also be used for pattern #2 above. Below is architecture for Pattern # 1 with Proxy – [Click on image to get better view].

Azure Architecture Pattern 4

While we can have entry point on Azure Internet DMZ Zone through F5 DDoS BIG IP on Azure VMs; we can achieve the high availability WITHOUT USING Azure Standard Load Balancer as well.

Refer to below diagram for the same - [Click on image to get better view].

In above diagram assuming we want to retain Source IP to Firewall level; we can configure DDoS F5 Azure VMs in Active-Passive.

In the diagram, for F5, in the event of a failover, the IP configuration is deleted from active device and recreated on that standby device’s network interface. So your public IP [virtual IP] on which traffic lands remain same irrespective of which VM is serving the requests.

This failover is API call based failover and well explained here - Azure(f5.com).

Same API based failover can also be achieved for F5 WAF device. Also you can keep adding secondary public IP addresses per application being onboarded behind this DMZ zone.

Azure Architecture Pattern 5

I have many organization using PaloAlto Azure VMs Firewall for outbound and inbound combined had to use bigger size VMs. There is another deployment pattern I have seen where separate Azure PaloAlto Firewalls are used for inbound and outbound.

In this pattern we will need to perform mandatory SNAT at F5 WAF level to allow return traffic reach to correct destination of F5 WAF and outbound traffic generated within app layer to reach to outbound PaloAlto Azure VM. Refer to below diagram for details - [Click on image to get better view].

Here we are having two public Ips attached to one of the NIC of each of outbound PaloAlto NGFW. So that based on current active VM the outbound traffic flow outside to internet.

Remember you will need UDR configured in app layer in such a way that traffic destined to internet will flow to PaloAlto NGFW Azure VMs and rest of the traffic should flow to F5 WAF.

Is there a way to run F5 BIG-IP DDoS on Azure on entry point in Active-Active with No SNAT?

If you want to preserve incoming source IP till firewall/ app layer then SNAT should not be used. If we plan to deploy F5 DDoS in Active-Active then SNAT is required. Otherwise return traffic does not understand which was VM devices to be used for return/ response traffic. In this case source IP of incoming traffic will not be visible to firewall. In such case many customers take below approach –

1.      Configure SSL Offload on F5 DDoS

2.      Configure F5 DDoS in Active-Active with SNAT.

3.      Add incoming Source IP in X-Forwarded-For [XFF] header.

This is fine if you firewall devices are able to block incoming malicious IP present in XFF. If not, then Active-Passive will make more sense.

Should I always have F5 DDoS on front irrespective of order of devices?

DDoS is for protection of traffic coming from internet. So for internet facing applications, you should always have DDoS in front of everything.

I see PaloAlto NGFW VM-Series on Azure is mentioned as Active-Standby / Active-Passive only? Can it work in Active-Active mode?

As of today PaloAlto VM-Series firewall on Azure can not work in Active-Active mode. Refer to the document for more information - VM-Series in High Availability (paloaltonetworks.com)

Do we need to perform SNAT on PaloAlto VM-Series Firewall?

If you don’t want to retain source IP forwarded from DDoS devices beyond PaloAlto NGFW Azure VMs then you can certainly perform SNAT on PaloAlto VM-Series Firewall Azure VMs. IF you want to retain source incoming IP till application layer then “Do not” perform SNAT on PaloAlto firewall device.

How to preserve Incoming Source IP of internet till Azure application layer VMs?

Many organizations require incoming source IP to be preserved till application layer/ firewall layer for monitoring/ business requirement/ logging/ audit purpose. If this is the case then you will need to configure the F5 DDoS Azure VMs in Active-Passive or Active-Standby mode.

This way Source IP of internet is not NATted on F5 DDoS Azure VMs and it is visible in PaloAlto NGFW layer. If SNAT is configured on DDoS then PaloAlto NGFW will never see real incoming source IP from internet.

Similarly to preserve the source IP beyond PaloAlto Azure firewall; you will need to avoid SNAT on PaloAlto Azure VM-Series and F5 WAF devices.

Refer to Pattern 5 which stated how can you have incoming source IP taken to App layer in XFF header through F5 WAF device. Or you can simply avoid SNAT n F5 WAF Azure VMs also and you will get source IP as internet IP in application layer..

Conclusion

There can be many combinations of the security devices of F5 and PaloAlto on Azure. The above mentioned architecture patterns I have seen at most of the places on Azure. Hope this article helped to design combination of F5, PaloAlto on Azure.

If you have any recommendations to make article better, reach out to me. I will be more than happy to update the article.

Happy NVAs on Azure!

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

Restrict Azure Firewall access from Owner and Contributors of Azure Portal

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

Acomplex design – Site to Site VPN, VNET Peering and 4 VNETs – how to solve using Azure Firewall?

Azure VM disk encryption, what should be my approach!

Bypass onpremises firewall to RDP or SSH into Azure VM

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

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

Start stop multiple Azure VMs on schedule and save cost!

ExportAzure VMs to CSV!

Azure Migration frequently asked questions, not easily answered!

Azure VM disk encryption, what should be my approach!