- Deploying an AWS EC2 Windows VM via PowerShell - Mon, Dec 16 2019
- Creating an AWS VPC with PowerShell - Fri, Nov 15 2019
- Configuring Azure Private DNS - Mon, Nov 11 2019
If you’ve done any kind of networking before, this will all be very familiar. It all starts with the vnet itself. I recommend you launch the Azure Cloud Shell to execute the command lines here in the article.
It’s up to you to pick PowerShell or Bash; I’ll use PowerShell for this article.
Creating the Resource Group ^
Everything in Azure needs to go into a Resource Group. This is easily done by calling the New-AzResourceGroup cmdlet.
New-AzResourceGroup -Name 4soResourceGroup -Location "Australia East"
The name parameter specifies the Resource Group’s name and the location parameter where this Resource Group is supposed to store its metadata. The resources themselves can then be deployed in any other region if we want to.
Creating the Virtual Network ^
Now, with the scaffolding out of the way, let’s create our vnet. For the purposes of this article, we will create a single vnet with multiple subnets controlled by Network Security Groups (NSGs).
When creating a vnet, it is important to know what IP range you will require going forward. Changing a vnet’s IP range is not supported, which means you must delete and redeploy everything (if you have already deployed resources into the vnet) if you need to change the IP range.
If you need to connect your Azure network to your on-premises network, those IP ranges must not overlap. Okay, I guess it’s safe to use a 192.168.0.0/16 network; there are plenty of IPs to use and lots of subnets available.
New-AzVirtualNetwork -Name 4soNetwork -AddressPrefix 192.168.0.0/16 -ResourceGroupName 4soResourceGroup -Location "Australia East"
This created the new vnet with exactly the address space we wanted. However, now we want to create some subnets in the network.
Creating a subnet
The way you structure your subnets depends on your environment; there are a lot of Microsoft documentation articles explaining some good architectures. I just want to call out a few things for your consideration:
- If you require connectivity to on-premises via a VPN or ExpressRoute, you will need to deploy a subnet exactly called GatewaySubnet. Exactly that. This is a reserved name for subnets that will host virtual network gateways.
- You can likely say good-bye to your “traditional” three tier “web-app-data” subnet layout for applications. At least if you are going to use any of the PaaS offerings that support vnet connectivity such as Application Gateways, App Services, Redis Cache, etc. These all require their own dedicated subnets.
Creating a new subnet is simple with PowerShell. This snippet will create the GatewaySubnet for us with a 192.168.0.0/27 IP range, offering enough addresses for multiple gateways. The first line assigns the vnet information to the vnet variable. The second line is where we define the subnet, and in the third line, we add that definition to the vnet configuration. The last line writes the subnet into the vnet.
$vnet = Get-AzVirtualNetwork -Name 4soNetwork -ResourceGroupName 4soResourceGroup $subnetConfig = New-AzVirtualNetworkSubnetConfig -Name GatewaySubnet -AddressPrefix 192.168.0.0/27 $vnet.Subnets.Add($subnetConfig) Set-AzVirtualNetwork -VirtualNetwork $vnet
Using the following snippet, we can add another subnet for a future jumpbox.
$vnet = Get-AzVirtualNetwork -Name 4soNetwork -ResourceGroupName 4soResourceGroup $subnetConfig = New-AzVirtualNetworkSubnetConfig -Name jumpbox -AddressPrefix 192.168.1.0/29 $vnet.Subnets.Add($subnetConfig) Set-AzVirtualNetwork -VirtualNetwork $vnet
At this point, we have two subnets in our vnet, one for a future VPN gateway and another for a future jumpbox into our environment.
Securing our subnets
The last step I want to touch on is securing our subnets. This is usually done using NSGs. An NSG already comes with default security rules that can be overwritten with custom rules. Microsoft does not recommend nor support adding an NSG onto the GatewaySubnet subnet but encourages everybody to use them on other subnets. So, in preparation for a future jumpbox, let’s configure an NSG that only allows ports 3389 (RDP) and 22 (SSH) inbound from the internet into the jumpbox subnet.
$rdp = New-AzNetworkSecurityRuleConfig -Name "allow-RDP-from-internet" -SourcePortRange * -Protocol TCP -SourceAddressPrefix Internet -Access Allow -Priority 110 -Direction Inbound -DestinationPortRange 3389 -DestinationAddressPrefix * $ssh = New-AzNetworkSecurityRuleConfig -Name "allow-SSH-from-internet" -SourcePortRange * -Protocol TCP -SourceAddressPrefix Internet -Access Allow -Priority 120 -Direction Inbound -DestinationPortRange 22 -DestinationAddressPrefix * New-AzNetworkSecurityGroup -Name jumpbox -SecurityRules $rdp, $ssh -ResourceGroupName 4soResourceGroup -Location "Australia East"
Clicking on our new NSG, we can see the details and the inbound rules we just configured with our code.
The very last step is to assign this NSG to our subnet.
$vnet = Get-AzVirtualNetwork -Name 4soNetwork -ResourceGroupName 4soResourceGroup $nsg = Get-AzNetworkSecurityGroup -Name jumpbox -ResourceGroupName 4soResourceGroup $subnet = Get-AzVirtualNetworkSubnetConfig -Name jumpbox -VirtualNetwork $vnet $vnetConfig = Set-AzVirtualNetworkSubnetConfig -Name jumpbox -VirtualNetwork $vnet -NetworkSecurityGroup $nsg -AddressPrefix $subnet.AddressPrefix Set-AzVirtualNetwork -VirtualNetwork $vnetConfig
This will assign the NetworkSecurityGroup jumpbox to the jumpbox subnet in the 4soNetwork VirtualNetwork. It’s a couple of lines of code, but after this, we can see that the subnet now has the NSG applied to it.