Tag Archives: cloud

Connect an on-premises network to Microsoft Azure with a site-2-site VPN

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Building networks in the cloud is sometimes hard to understand. A common mistake is to believe that all VMs can talk to another, regardless of the owner, and that all VMs are available over the internet.

Some basics about Cloud Service Endpoints and Virtual Networks

When we talk about Microsoft Azure, a Cloud Service Endpoint is the easiest way to access one or multiple VMs. A Cloud Service contains resources, like VMs, and it’s acting as a communication and security boundary. All VMs that use the same Cloud Service get their IPs via DHCP and share the same private IP address range. The VMs can communicate directly to each other. To access these VMs over the internet, a Cloud Service Endpoint is used. Each Cloud Service has a internet addressable virtual IP address assigned. And that’s the Cloud Service Endpoint. With PAT, ports for RDP or PowerShell are forwarded to the VMs by default. If you deploy a webserver and an application server, both can be provisioned to the same Cloud Service and therefore, they share the same Cloud Service Endpoint. But you can only forward http traffic to the webserver. Therefore only the webserver is available over the internet, not the application server.

If you need more complex networking within Microsoft Azure, you may take a look at the Virtual Networks (VNets). VNets are used to create and manage isolated networks within Microsoft Azure. Each VNet has its own choosable IP address range. VNets can be linked to other VNets and on-premises networks using VPN techniques. VNets allow you to assign “your own” IP addresses to VMs. To be honest: You can define “your own” IP subnet, but even with Set-AzureStaticVNetIP, you can’t assign a real static IPs to those VMs. It’s more a kind request to get the same IP everytime the VM boots up.

With VNets you can extend your on-premises network to Microsoft Azure. You can deploy test and development environments to Microsoft Azure and connect to the used VNets using IPsec. Or you can run you whole datacenter within Microsoft Azure and only have PCs and laptops on-premises.

Connect a on-premises network to Microsoft Azure

In this blog article, I’d like to show you how you connect your on-premises network to a Microsoft Azure Virtual Network. In this case, I used my AVM FRITZ!Box 7270 as the VPN gateway in my on-premises network. Many well-known manufacturers are listed on the compatibility list.

The very first step is to create a Virtual Network (VNet) in the Microsoft Azure portal. Select “NETWORKS” from the left panel and create a new VNet.

azure_site-2-site_1

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

You should assign a descriptive name to your VNet. Just an information: The datacenter for the local “West Europe” is located in the Netherlands. Currently there is no datacenter in Germany.

azure_site-2-site_2

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

If you have a DNS server in your local network, you can add it in step two of the “Create a Virtual Network” wizard. Make sure that you select the “Configure a site-to-site VPN” checkbox. Otherwise you can’t create a IPsec tunnel.

azure_site-2-site_3

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

In the third step, you have to enter details about your on-premises network and the VPN device. The VPN device address is the public address of your VPN gateway. You have to use an IP address here. You can’t use a FQDN. So make sure that you have a static IP address! I don’t have one. This means that I have to change my VNet config each time my public IP changes (all 24h). Enter the address spaces of your local IP subnets.

azure_site-2-site_4

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The “Virtual Network Address Space” defines the IP subnet which should be used for the VMs that will be provisioned to this VNet. And you have to add a subnet for the gateway. The gateway subnet is used for the IPsec connection. Please note that this subnet can’t be used for VMs.

azure_site-2-site_5

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The creation of the VNet takes some time. After a couple of minutes you should be able to click on “VIRTUAL NETWORKS”, “LOCAL NETWORKS” and “DNS SERVERS” and you should see the values you’ve entered.

azure_site-2-site_6

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

In the “LOCAL NETWORKS” section you can see the address space of your local network, as well as the IP of your VPN gateway. If you don’t have a static IP address, you have to change the VPN gateway address here everytime the IP address changes.

azure_site-2-site_7

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Last but not least: The DNS server of your local network.

azure_site-2-site_8

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The next step is to create a gatway. The gateway is necessary for the IPsec connection. Click on “CREATE GATEWAY”.

azure_site-2-site_9

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Select “Static Routing”. That’s all. The creation of the gatway will take some time. I had to wait about 5 minutes until the gateway was created.

azure_site-2-site_10

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

After the creation of the gateway, you should see the gateway IP address. This address is the VPN endpoint from the perspective of your local network.

azure_site-2-site_11

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Beside the gateway IP address, you also need the shared key to create an IPsec tunnel. Click on “MANAGE KEY” to get the pre-shared key.

azure_site-2-site_12

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Copy the pre-shared key and save it for later use.

azure_site-2-site_13

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Now the configuration of the VNet is finished. Now it’s time to configure your on-premises VPN gateway. In my case it’s a AVM FRITZ!Box which isn’t listed on the compatible device list. You have to create and import a config file. This is the config file I’ve used. I highlighted the parts of the config that you have to modify. Please note, that previously created VPN connections may be deleted if you import this file. If you have additional VPN connections configured on your FRITZ!Box, please make sure that you add them to this file BEFORE you import it.

You can use my config as a template for your VPN config. Simply change the highlighted values, remove the comments and import it into your FRITZ!Box. Don’t forget to remove the comments in the config file. Don’t remove the comments at the beginning of the file. Only remove the comments I added to highlight the values you have to change. If everything’s fine, the IPsec tunnel should be established within a couple of seconds.

azure_site-2-site_17

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

As soon as the IPsec tunnel is established, you should be able to ping the gateway IP address. In my case it’s the IP address 192.168.186.37.

azure_site-2-site_19

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

If you create a new Azure VM, you can now use your newly created VNet and subnet. Simply choose the VNet from the “REGION/ AFFINITY GROUP/ VIRTUAL NETWORK” drop down menu.

azure_site-2-site_20

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The first VM will get the IP address 192.168.186.4. Why the .4 when the first usable address is .1? The first four IP addresses of the address space are reserved. So the first usable IP address is 192.168.186.4. The second VM will get the 192.168.186.5 and so on. The same applies to the gateway address space.

Now, with a working IPsec tunnel to my VNet, I can open a RDP connection to my newly created VM using the IP address 192.168.186.4. And there it is:

azure_site-2-site_22

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

If you connect your on-premises network to Microsoft Azure, you should know that you can use up to 80 Mbps with an availability SLA of 99.9% and no performance commitment! If you need more bandwidth, you can use a High Performance Gatway which can deliver up to up to 250 Mbps.

I would recommend to use VNets whenever it’s possible. Not only in case of connecting a on-premises network. If you wish to use VPN features, take a look at the VPN gateway compatibility list! Otherwise, the connecting your on-premise network to Microsoft Azure might be a bit fiddly.

IaaS by VMware: VMware vCloud Hybrid Service

This posting is ~6 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

VMware vCloud Hybrid Service (vCHS) stands in one line with Amazon Web Services, Microsoft Azure, Rackspace Cloud or other cloud offerings. I don’t want to compare the different provider with vCHS. To be honest: This article is more a summary for myself, than really new content. I just want to summarize information about the IaaS offering of VMware. If you want a comparison of vCHS and AWS, I recommend to read this article written by Alex Mattson (AHEAD).

Introducing VMware vCloud Hybrid Service (vCHS)

VMware vCHS isn’t a tasty cheese (please DON’T pronounce it “vCheese”…), it’s a public cloud IaaS offering by VMware. And because public cloud concepts are no cheese, you should stick your nose into it more closely. VMware vCHS is built with the same VMware products that you’re using in your private datacenter. Because of this vCHS is compatible to your private VMware environment and you can move VMs between your private datacenter and VMware vCHS. You can use vCHS to move workloads to a public cloud environment, or you can use it to start a new deployment. Sure you can move workloads vom vCHS to your private datacenter.

Core Compute Services

VMware offers two core compute services: Dedicated Cloud and Virtual Private Cloud. Both provide a pool of compute, storage and networking resources. Dedicated Cloud is, as the name says, dedicated to a single-tenant, physically isolated with a dedicated management stack. 100% of the resources are reserved and can be allocated depending on customer needs. The customer can assign the resources to virtual dedicated clouds. Each virtual dedicated cloud provides individual access and control over the resources. Virtual Private Cloud is multi-tenant and logical isolated. The infrastructure is shared among several tenants. The virtual private cloud is ideal for testing or peak workloads. Both core services can be extended by various options. CPU, memory, storage and IP addresses can be added in increments to both compute services.

Business Continuity

VMware offers two services to protect your private and cloud-based VMs: vCHS Disaster Recovery and vCHS Data Protection. vCHS Disaster Recovery is based on vSphere Replication. With vCHS Disaster Recovery you can replicate VMs from your private datacenter into your vCHS environment, regardsless if you have a dedicated cloud or virtual private cloud. vCHS Data Protection is used to protect the VMs, that are running in your vCHS dedicated cloud or virtual private cloud environment.

Management Tools & Networking

Beside the core compute services and services like vCHS Disaster Recovery and vCHS Data Protection, VMware offers, and supports tools and applications to increase the value of vCHS. You can use the free vCloud Connector to migrate VMs from your VMware vSphere or vCloud environment to a vCHS dedicated cloud or virtual private cloud. VMware vCloud Automation Center can be used together with vCHS, e.g. users can provision multi-tier applications in vCHS by using vCAC self-service. vCHS takes care of the infrastructure deployment, vCAC controls the application deployment and enforces governance. With the vSphere Web Client Plug-in you can manage your private VMware environment and your vCHS environment through the same client. Offline Data Transfer (ODT) can be used for bulk uploads of VMs, templates, vApps etc. An encrypted device is provided by VMware to store the data for the transfer. Regarding networking VMware offers vCloud Hybrid Service Edge Gateway and Direct Connect. The edge gateways provides features like firewalling, NAT, IPSec VPN and load balancing. Director Connect provides high bandwidth (1 Gbps and 10 Gbps) connections to connect vCHS to your private datacenter. Direct Connect is a service provided by VMware and VMware Direct Connect partners.

Pricing

For pricing you should visit the vCHS Pricing & Comparison website, but to give you a clue: A virtual private cloud (20 GB, 5 Ghz, 2 TB storage, 10 Mbps bandwidth and 2 public IPs) costs ~ 1.200 € per month.

Final words

vCHS is a great product and there are dozens of use cases for it, e.g. disaster recovery with vSphere Replication. Good news for vExperts: VMware has re-launched the vExpert access to vCHS. Participants can use vCHS for 30 days. A great chance to demonstrate this to potential customers!