Extending Private Data Center to Azure Cloud – Part 2

In Part 1 of this article, I talked about network and system design issues related to scalability, redundancy and security for deploying a 3-Tier application in a private Data Center (DC). It is more a theory-only article. Parts 2 and 3 of this article are more hand-on where we will deploy this web application and its associated network setup on Azure while maintaining control of the application from the private DC (i.e., Hybrid Cloud).

All Cloud Service Providers (CSP) are competing fiercely for your Cloud service business and they all offer free trial accounts. With an Azure’s free trial account, you can deploy this 3-Tier web application on Azure and try it out for free.

Azure’s Reference Architecture

All CSPs document their cloud deployment best practices to expedite user learning and cloud service deployment. They call these best practices Reference Architecture. I found Azure’s Reference Architecture very well organized and documented. Particularly, Azure goes extra miles to include deployment scripts for each reference architecture example to simplify and expedite Azure Cloud service learning and deployment. Hybrid Cloud is a common cloud deployment scenario and thus Azure has a reference architecture example called DMZ between Azure and your on-premises datacenter. Therefore, instead of reinventing the wheel again to develop our 3-Tier application on Azure from scratch, we will take advantage of this Azure’s reference architecture example and its accomplishing scripts to illustrate running a 3-Tier application on Azure. I will highlight the difference between the network design in Part 1 of this article and the Azure’s reference architecture DMZ example throughout this article. 

The following shows the high-level network diagram of Azure’s Hybrid Cloud example, DMZ between Azure and your on-premises datacenter:

Azure Hybrid network

The On-premises network on the left-hand-side of the diagram is the private Data Center (DC) that we discussed in Part 1 of the article. The eBGP and Internet traffic diversion from the on-premises network to Azure are not shown in this Azure’s reference architecture example as it is beyond the scope of the example. For readers who are interesting in learning eBGP peering and policy, please refer to my previous article, ISP Peering with BPG traffic Steering Policy – Nokia SR and Cisco XR.

The virtual network on the right-hand-side of the diagram is the 3-Tier web application we discussed in Part 1 of the article and it is now running in Azure. The Firewall/DMZ in Part 1 of the article is now the Private DMZ in and Private DMZ out. There are Network Security Groups (NSGs) in each subnet or layer for blocking and passing TCP/UDP ports etc… They are implemented in the Firewalls in Part 1 of the article.

Azure Building Block (azbb)

Most Azure’s reference architecture examples come with deployment scripts to simplify and expedite cloud service deployment and learning. There are many ways to program and deploy resources on Azure such as:

  • Azure web portal
  • Windows Powershell using Resource Manager CLI
  • az CLI
  • Azure Building Block (azbb)

azbb is an open-source command line tool and set of Azure Resource Manager templates designed to simplify deployment of Azure resources. It uses JSON format and thus the code is very self-explanatory. Most Azure’s reference architecture examples come with azbb scripts. 

For Azure’s DMZ between Azure and your on-premise datacenter example, it comes with the following azbb scripts:

  • onprem.json
    • Setup VMs and network on the virtual network, onprem-vnet to simulate the private DC to complete the example and testing
  • secure-vnet-dmz.json
    • Setup VMs and network on the virtual network, ra-vnet on Azure. This is the actual 3-Tier web application production script

Follow the deployment instructions on the URL to install Azure CLI 2.0 and Azure building blocks (azbb) npm package on your Windows PC. After successful installation, invoke a Windows Command Prompt and execute the two azbb scripts to setup the on-premise (i.e., private DC) and web application networks on Azure:

azbb -s subscripton_id -g resource_group_name -l region -p onprem.json --deploy

azbb -s subscripton_id -g resource_group_name -l region -p secure-vnet-hybrid.json --deploy

Make sure you substitute your Azure subscription_id, resource_group_name, and region onto the above commands. If everything works fine, you will end up with the following systems and networks on Azure.

VISIO redraw

The above network diagram is very useful in explaining the operations of Azure for hybrid cloud operations and the azbb deployment scripts. Note that onprem-vnet has the IP prefix of 192.168.1.0/24 in my example. In the original Azure’s reference architecture DMZ example, it is 192.168.0.0/16. This is because in my next article, I will be using my home LAN (192.168.1.0/24) as the on-premise DC to run Nokia’s 7750 Service Router on GNS3 on a Windows PC to create an IPSec tunnel to Azure for Hybrid Cloud operations. For the secure-vnet-dmz.json script, I keep it intact.

The execution of the two azbb JSON scripts will take about 3 hours to complete as there are many Load-Balancers, Jumpbox, Apache VMs etc.. need to be created. Once the systems and networks are created, restarting them will take only a minute. If you want to maximize your free Azure credits, you may want to start the Azure setup only when you are actually using it.

The two public IP address 40.115.6.5 and 137.117.249.141 for the onprem-vpn-gateway1 and the ra-vpn-vgw VPN gateways respectively are assigned by Azure in an on-demand basis. Therefore, you will get different public IP addresses when you run the two azbb JSON scripts.

Jumpbox VM and Azure Web Application Verification

A Jumpbox VM called jb-vm1 is created by the onprem.json script. jb-vm1 is simply a Windows PC created using Azure’s VM image, Standard_DS1_v2. The following shows the jb-vm1 VM creation JSON code in the onprem.json script:

           "type": "VirtualMachine",
                    "settings": {
                        "vmCount": 1,
                        "namePrefix": "jb",
                        "size": "Standard_DS1_v2",
                        "adminUsername": "testuser",
                        "adminPassword": "AwesomeP@wd",
                        "osType": "windows",
                        "virtualNetwork": {
                            "name": "onprem-vnet"
                        },

From the Azure portal, we can find the public IP address, 23.97.246.41 assigned to jb-vm1. We need this public IP address in order to remote desktop to the VM to verify the 3-Tier web application setup on Azure.  

JB public IP

When an operator from the private DC (i.e., on-premise network) wants to manage the Azure web application over Internet, the operator will remote desktop to the Jumpbox, jb-vm1. Jump-in-time access and TCP/UDP port restriction are applied to the Jumpbox VM to limit operator access to the web application on Azure for added security.

When the operator successfully accesses jb-vm1 via remote desktop using the pre-defined userid and password (i.e., testuser, AwesomeP@wd) defined in the onprem.json script, the operator can invoke a web browser from jb-vm1 to go to http://10.0.0.20, which is the frontend address of the Load-Balancer of the Web Tier on Azure.

The following shows the Effective Routes table of jb-vm1 created by the onprem.json script:

JB effective routes

Web traffic for IP subnet 10.0.0.0/16 will go through onprem-vpn-gateway1 with the public IP address of 40.115.6.5. In other words, traffic between the on-premise network and Azure is through an IPSec tunnel and thus traffic is encrypted for data privacy. The following shows the path of the web traffic from jb-vm1 to the Azure web application on the virtual network, ra-vnet:

  • Local Gateway, onoprem-vpn-lgw
  • Connection, onpremvpn-cn
  • VPN Gateway, onprem-vpn-gateway1
    • Traffic is IPSec encrypted between the two VPN Gateways
  • VPN Gateway, ra-vpn-vgw 
  • Local Gateway, ra-vpn-lgw 
  • Load Balancer, int-dmz-lb’s nva-lb-fe (10.0.0.20) 

If everything is set up correctly, a test page is served and showed on jb-vm1’s web browser when the browser points to the front-end address (e.g., 10.0.0.20) of the loader balancer nav-lb-fe for dmz-in as follows:

remote desktop JB to web

If you get the above web page on the web browser on the jb-vm1 VM, congratulations, you have successfully deployed the web application on Azure as well as the test VM on the on-premise test network (i.e., private DC). We can now proceed to analyze the networks and systems created on Azure by the two azbb JSON scripts. 

VPN and Local Network Gateways, and Connection

The on-premise network created by the onprem.json script is for testing the Azure web application only. In an actual deployment for extending a private DC to Azure cloud, one can either enhance the DC gateways to support IPSec operations or simply deploy a separate IPSec box to encrypt traffic between the private DC and Azure. The following shows the IPSec routers that have been validated by Azure for private DC deployment:

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices

In Azure, an IPSec Gateway is manifested by the following Azure resources:

  • VPN Network Gateway
  • Local Network Gateway
  • Connection

A VPN Gateway is a specific type of Virtual Network Gateway in Azure that can form an IPSec tunnel to its remote counterpart to encrypt traffic for data privacy.

The following Azure resources are created by the onprem.json script for IPSec operations. A similar set of Azure resources are also created on the virtual network, ra-vnet to support data privacy for the web applications:

  • VPN Network Gateway – onprem-vpn-gateway1
  • Local Network Gateway – onprem-vpn-lgw
    • Contain a route of 10.0.0.0/8 with next-hop 137.117.240.141 so that all web traffic to 10.0.0.0/8 on Azure go through the VPN gateway, onprem-vpn-gateway1
  • Connection – onprem-vpn-cn
    • Connect the VPN and Local Network Gateways
    • Hold the shared key for the IPSec tunnel of the VPN Gateway. Both the VPN Gateways on the virtual networks, onprem-vnet and ra-vnet need to have the same shared key to set up the IPSec tunnel

On the Local Network Gateway, onprem-vpn-lgw, the IP address 137.117.240.141 represents the public IP address of the destination VPN gateway, ra-vpn-vgw. The Address space shows the prefix of traffic that needs to go through the IPSec tunnel for data encryption and privacy.

on-premises Local Gateway

Different sizes (i.e., number of tunnel, connection, throughput etc…) of VPN Gateways can be selected based on SKUs under Azure. In the below example, VpnGw1 SKU is selected with an aggregated throughput of 650Mbps and maximum 10 concurrent IPSec tunnels. Again, in a real deployment, a physical or virtual (e.g., inside DC Gateway) IPSec gateway can be used in the on-premise network or the private DC.  

vpn gateway

The VPN Gateway has a connection, onprem-vpn-cn to the Local Gateway, onprem-vpn-lgw.

VPN Gateway connection

When Double-Click on the connection, onprem-vpn-cn, it revives the connection is for the Local and the VPN Gateways. The Shared key used by the VPN Gateway for IPSec operations can be obtained via this screen.

connection

Conclusion

Part 2 of this article discusses the two virtual networks, onprem-vnet and ra-vnet that are created by the two azbb scripts from the Azure reference architecture DMZ example. This saves us from creating our own 3-Tier application for this example. The setup of the Jumpbox, and Azure resources such as the Local Network Gateway, VPN Gateway and Connection are discussed for extending the on-premises network or the private DC to Azure to support hybrid cloud operations.

In Part 3 of this article, we will talk about the Azure web application and its associated network setup such as NSG, Load-Balancer, and DMZ network segmentation etc… created by the second azbb script,
secure-vnet-hybrid.json. See you there.  

Advertisements

One thought on “Extending Private Data Center to Azure Cloud – Part 2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s