Customise IKE/IPsec Policy for Azure Virtual Network Gateway Connection Object

Microsoft has given us the ability to define custom IKE/IPsec policies for use with the native Virtual Network Gateway. In the past, the on-premise peer device had to support the fairly limited protocols suites that were statically set on the Virtual Network Gateway. 

It should be noted that custom IKE/IPsec policies are set at connection object level and not on the Virtual Network Gateway itself, this offers greater flexibility when you have multi-site VPN connections terminated on a single Virtual Network Gateway. This example covers how to create a custom policy for an S2S VPN connection, it is also possible to apply custom policies to vNet to vNet connection. Although this may not be as commonly done after vNet Peering becoming GA. 

Please note that in this example the Virtual Network Gateway along with the Local Network Gateway has already been defined in my subscription. The Local Network Gateway is the resource that contains the remote VPN peer address etc.

This command creates the new policy and stores it in a variable called $policy, this will be referenced when we are creating the new connection object.

$policy = New-AzureRmIpsecPolicy -DhGroup ECP384 -IkeEncryption AES256 -IkeIntegrity SHA384 -IpsecEncryption GCMAES256 -IpsecIntegrity GCMAES256 -PfsGroup

This command stores the Virtual Network Gateway you want to create the connection object on and stores it in a variable called $gateway.

$gateway = Get-AzureRmVirtualNetworkGateway -Name "rbVNG01" -ResourceGroupName "rbRG1"

This command stores the Local Network Gateway object in the variable $remote

$remote = Get-AzureRmLocalNetworkGateway -Name "TW-2-AZ" -ResourceGroupName "rbRG1"

This command creates the connection object and applies the newly created policy.

New-AzureRmVirtualNetworkGatewayConnection -Name "TW-2-AZ" -ResourceGroupName "rbRG1" -VirtualNetworkGateway1 $gateway -LocalNetworkGateway2 $remote -Location "UK South" -ConnectionType IPsec -IpsecPolicies $policy -SharedKey "VerySecretCode"

Please review this article for full details on the supported protocol suites etc.

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-ipsecikepolicy-rm-powershell

Azure Networks Configuring Address Spaces, Subnets and Configuring Azure VM's with Azure Networks

Azure Networks are Network Services that can be designed and configured to support complex network infrastructure, supporting both on-premise and cloud based workloads. I have found certain Azure Virtual Network configurations easier to do from the Azure Portal, which is still in Beta/Preview mode. You can use it to configure your subscription http://portal.azure.com

Designing Azure Networks is must like designing and provisioning traditional networks, at a high level the following steps are required to define Azure Networks;

·       Create Virtual Network (which is a Network Service)

·       Assign Address Space and Subnets to Virtual Network

·       Configure Additional Subnets for the Virtual Network

All the traditional principals of TCP/IP address design are the same when designing Azure Virtual Networks. An Address Space, is usually defined as an RFC 1918 CIDR block which are

·       10.0.0.0/8

·       172.16.0.0/12

·       192.168.0.0/16

You can then define Subnets within that Address Space to separate network traffics, like you would in a traditional network. An example of how I have configured this Azure Virtual Network is

·       192.168.1.0/24 (Servers)

·       192.168.2.0/24 (DMZ)

·       192.168.3.0/24 (On-Prem)

The Subnet Mask (written in CIDR notation above) can be altered to make your Subnets bigger, or smaller. You should design out your networks on paper if you are going to change the Subnet Masks, and move to a class-less network design. This is to ensure your logical network stay contiguous.

From the Azure Portal, click New, then Networking, then Virtual Network. You must populate the Name field with something unique. Click Address Space, and then input your Address Space from the Address Space column. At this point in the Azure Virtual Network creation you only create a single subnet, in my example below I have called the Subnet "Servers" and it uses the subnet 192.168.1.0/24. Click OK to create the Virtual Network.

Return to the Azure Portal Home screen, and the newly created Azure Virtual Network will appears as a tile object, click on the tile mine is called "vNetwork-Test".

To add additional subnets to the Azure Virtual Network click Subnets.

Click Add Subnet button.

Populate the Name field, this a unique and descriptive name for the Subnet. Also set the Address Space to the Address Space you want this subnet to reside in, this example Azure Virtual Network only has one. Also enter a CIDR Block, I used 192.168.1.0/24 for my Servers subnet so 192.168.2.0/24 is the next available logical piece of network space. It would be my recommendation to design these so that overlaps and class-less networking is avoided if possible.

You can then add any of the subnets you require for your Azure subscription.

The next part is creating a new Azure Virtual Machine, and adding it to the correct Virtual Network and Subnet. This is something I believe you cannot do from the current Management Portal (please correct if you can). From the Azure Portal, click New, Compute and then select the Operating System, name the VM, and give it a username and password. Click on Optional Configuration.

From Optional Configuration click Network, then select your Azure Virtual Network, the Subnet you want the VM to be in and click OK. It's worth mentioning that once a VM has been configured inside a Virtual Network it cannot be move to another network, the only way to do it is to delete the Azure VM and retain the disks. You can then create a new VM from the old disks and connect it to a different network, I would imagine this will change at some point as Azure matures.

From the same Network pane you can also configure the VM with a static TCP/IP address within the same logical subnet that you are connecting the VM to.

An Azure Network also has a DNS Server, if you do not configure it to use a DNS Server it will  automatically point to one of the Azure hosted DNS servers. You can of course configure this to be your own DNS server(s) or even a global DNS provider.