I've been getting my feet wet with Azure as we might be building a new infrastructure and services there.
We currently use VMWare so I am very familiar with creating VM's, networking them (even in different subnets, etc). I'm still getting used to the way Azure does networking, subnets and VPN's.
When creating a basic network inside Azure you need two things:
- Address Space
- Subnets
For those of us who have been building networks for years, this can sound extremely confusing. An address space is already part of a subnet. For example, if you have a network of 192.168.0.0/24, the /24 is your subnet. This gives you 256 IP's (192.168.0.1-0.255) and the subnet mask would be 255.255.255.0. So why do I need to create both? Shouldn't Azure just know what my address space is based on my subnets?
I can't speak for the Azure engineers but the only thing i can think of is they wanted organization and for it to be easy for people who have never created network before.
You start by creating a new Virtual Network. When you create a new VNet, it will ask for your address space and a subnet.
ADDRESS SPACE
Let's start with the address space. This will be represented using a CIDR range. For example, you can get crazy and put in 192.168.0.0/16. This will give you a huge amount of IP's (192.168.0.1-192.168.255.254). You can name the Address space something like Main Network
Creating the address space is only the first step. Without creating a subnet you can't do much (at least in Azure). The address space in Azure is just a place holder letting Azure know the network space you want to work with and give your VM's.
SUBNETS
Here is where you will break up your networks into logical chunks. Even though your address space is 192.168.0.0/16, your first subnet could be 192.168.0.0/24. This will give you IP's from 192.168.0.1-192.168.0.254. You can name the subnet something like Servers.
After you create this VNet, you can go back in an create more subnets where the VM's will live. You could create another subnet 192.168.1.0/24 and name it Desktops.
One thing to keep in mind is that even though they are on different subnets, because they are in the same address space in Azure, they can talk to each other without needing a gateway (I mean, there is a gateway but Azure handles all of that in the background).
The only exception to this is if you create another address space, lets say 172.16.0.0/16. If you create this address space and then create subnets underneath that, you will need to create a VNet to VNet gateway if you want these to Address Space/Subnets to talk to each other. For this to work they must be in the same Azure location (IE, South Central US).
When you start creating new VM's you will be asked which Virtual Network you want to use and then which subnet you want to use.
VPNs
VPN's are a little confusing inside Azure. I hope to be able to do a more in depth post on VPN's but for now I will briefly discuss how you set them up.
Azure has pretty much three type of VPN's Point to site, Point to Point and Express Route. Broken down they are:
Point to Site - Point to Site is basically a windows client connecting to the Azure network.
Point to Point - Point to Point is what I know as Site to Site. You will need a VPN device to connect to Azure.
Express Route - Express route is a direct connection from your office directly to an Azure data center. Its like an MPLS. It doesn't go through the internet. Its a direct private link to your Azure environment.
POINT TO SITE
To create a point to site you will need to go to your Virtual Network that you created, go to subnets and add a GatewaySubnet. I've been trying to find more info on why this is needed but I can't find a definitive answer. I'm assuming its a bridge between the Azure network and you. When you setup the GatewaySubnet, it will use a subnet from your available address space. Most articles say to give it a /28 or /27 CIDR to make sure you have enough IP's if you will be adding several VPN connections.
Once you create the GatewaySubnet, create a new Virtual Network Gateway. When creating this new VNet Gateway, make sure you select the correct VPN Type. Most people will use Route based (I had to use Policy based. I'll explain when i talk about Point to Point).
Gateway Type will be VPN. Create a name, select your virtual network and Public IP (create a public IP if need be). Once you click create, it could take up to 45 minutes before its provisioned.
Once the VNet Gateway is created, select it and select Point to Site Configuration. From here you will create an address pool and upload a root certificate.
The address pool is the IP address the windows client will receive when connecting to the VPN. When creating and address pool make sure it doesn't conflict with anything on the Azure network side or your internal network side. I wont go into detail on how to create a root cert but you can do this using makecert.exe. I used the Windows 10 SDK to create both a root cert and a client cert. The root cert you have to export (without the private key) to a X509 certicate and upload the data (copy and paste from notepad) into the Public Certificate Data box inside the Point to Site configuration.
Once you have all of the info filled out you can save the configuration and then download the VPN client.
POINT TO POINT
Point to Point requires more work because you need to make sure you configure your VPN device correctly. I used a watchguard firewall. But you can use Cisco, Juniper, etc. One thing to keep in mind is if you will be using Policy based or Routing based VPN. My watchguard only does policy based.
When I created my VNet Gateway initially I choose Policy based. Make sure you choose correctly. If you don't you will need to delete and recreate your VNet Gateway since the Point to Point VPN attaches to a VNet Gateway and you can only have one VNet Gateway attached to your Virtual Network. If you have multiple Virtual Networks then I assume you can have different VPN types.
Once you've determined the correct VPN type, create a Virtual Network Gateway if you don't have one already. Once you do that, you will need to create a new Local Network Gateway. Give it a name, the public IP address of your VPN device, your local IP address scheme in CIDR format that you use in your office, Azure location and click create.
Once its created go inside the Local Network Gateway and select connections under settings.
Click add, give it a name, attach it to a virtual network gateway and a Local Network Gateway. The next option is a pre shared key. Make this key long and something you will remember. My device only accepts letters and numbers. This key will be used in Azure and your VPN device.
Connection type should already say Site-To-Site and be grayed out.
Once you create this connection, you will need to setup your VPN device in your office. The Public IP for your office device to connect to will be listed in the Local Gateway Network under the connection you just created.
HERE is a link that shows whats devices are supported and if they are Policy based, Route based or both.
EXPRESS ROUTE
I have not been able to create an express route since we have not gotten to that point yet but from what I see you will need a circuit id that will be provided by your current (MPLS) provider. You will need to create an new ExpressRoute Network Connection and fill out the info. Your MPLS provider should have the info.
EDIT 4-23-18: To create an Express route you need to add it from the networking area. Once you do you will need the service key listed and you will give that to your MPLS provider. Once they have this they will provision the circuit. Here is where it gets confusing. Microsoft calls the network connection Peering. They have three types:
1. Azure Private
2. Azure Public
3. Microsoft
Azure private is what it says. It creates a connection from your MPLS to Azure without the need for a VPN.
Azure Public lets you connect to Azure Public IP's through a private link.
Microsoft lets you connect directly to O365 (Exchange Online, Sahrepoint, Skype, etc) and Dynamics Apps without going through the internet.
A few things to note:
1. Azure Public is being phased out.
2. To use Microsoft Peering you need permission from Microsoft before your MPLS provider will provision this for you.
3. Make sure you tell your MPLS provider which of the three you want.
Once it's provisioned they will give you some VLAN, ASN and IP info. you enter that info and then create a virtual gateway and then add a connection from inside the provision circuit and point it to the virtual gateway. When I did this everything started working since my MPLS provider was sending BGP and it knew what IP's were my local network. Microsoft support also did some stuff on their end as I did have to call support for some help.
Thats about it. If I get a chance I might put pictures and more details in another post. I'll put each connection type in it's own post.
POLICY OR ROUTE BASED?
This is from Microsoft's Azure site:
What is a policy-based (static-routing) gateway?
Policy-based gateways implement policy-based VPNs. Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the combinations of address prefixes between your on-premises network and the Azure VNet. The policy (or Traffic Selector) is usually defined as an access list in the VPN configuration.
What is a route-based (dynamic-routing) gateway?
Route-based gateways implement the route-based VPNs. Route-based VPNs use "routes" in the IP forwarding or routing table to direct packets into their corresponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the tunnels. The policy or traffic selector for route based VPNs are configured as any-to-any (or wild cards).
