Azure

What is Azure Private Link?

Azure Private Link is a technology designed to provide private connectivity to selected PaaS services, customer-owned and partner offered services.

Private Link allows you to access services over a private endpoint deployed into your virtual network. All traffic privately traverses the Microsoft global backbone, eliminating any exposure to the public internet and increasing security.

With no need for additional network resources such as gateways, NAT devices and public IP address network complexity is also reduced.

There are two key components of Azure Private Link:

  • Private Endpoint – a network interface connected to your virtual network, assigned with a private IP address. It is used to connect privately and securely to a service powered by Azure Private Link or a Private Link Service that you or a partner might own.
  • Private Link Service – your own service, powered by Azure Private Link that runs behind an Azure Standard Load Balancer, enabled for Private Link access. This service can be privately connected with and consumed using Private Endpoints deployed in the consumer’s virtual network.

Benefits of Private Link

  • The service can be used to connect virtual networks with overlapping address spaces
  • Secures access to services over the Microsoft backbone
  • Allows private access to services running in Azure from on-premise or peered networks
  • The service can connect to resources running in other regions offering global reach
  • Ability to enable private link access to your services
  • Supports various PaaS, partner and customer-owned services

An up to date list of services that support Private Link and region availability can be found here.

How do Private Endpoints differ to Service Endpoints?

One key difference between the technologies is that although a Service Endpoint can be restricted to only accept access from a specific virtual network, it is still accessed over a public endpoint. This is in contrast to a Private Endpoint which is created with a private IP and maintains network traffic within the Microsoft backbone.

Service endpoints are also only locked down to a specific service, not a specific resource. Whereas with Private Link, the private endpoint allows more granular access to the specific sub-resource.

Creating a Private Endpoint

Private Link Center is the management tool used for creating and managing Private endpoints and Private link services. In the search bar at the top of the Azure portal type private link, then select the service from the dropdown menu.

To begin creating a private endpoint, select Private endpoints from the left menu. Then from the top ribbon click + Add to open the Create a private endpoint wizard.  

The first thing we need to do is name the endpoint instance and define where it is to be created. Not only geographically in terms of the region but also in which subscription and resource group.

Now we need to define which resource and sub-resource the private endpoint allows access. Selecting a resource in your own directory is done using drop-down menus. Initiating a connection request to a resource in another tenancy is achieved using the resource ID or alias.

In this example, we are configuring the Private Endpoint to provide access to Blob storage. File Shares, Queues or Tables will not inherit the same access permissions. This enables us to be prescriptive and secure resources to a level not possible using Service Endpoints.

The next step is to configure the virtual network and subnet where the endpoint will be deployed.

It is also advised that a private DNS record is created and used when accessing the service via the endpoint. This can either be hosted by your own DNS solution or integrated with an Azure private DNS zone.

To make testing in this example easier, we will choose to integrate with an Azure private DNS zone.

The penultimate step is to define any tags before clicking Review + Create.

Assuming that validation passes successful, the final step is for us to click on Create to kick off the deployment process.

Browsing to the newly created endpoint, we can see from the overview page details such as its network interface, the virtual network and subnet its connected, FQDN and assigned private IP address (10.0.0.5).

Jumping to the storage account the endpoint was linked with and expand the Firewall and virtual network tab. We see that the only access allowed is for trusted Microsft services.

Switching to the Private endpoint connections tab, we should be able to see listed the private endpoint that’s just been created. If configured correctly, the connection state should appear as Approved.  

Now everything has been configured, we can go ahead and test access to the storage account is only allowed through our private endpoint.

From a virtual machine connected to the same virtual network, open a PowerShell console and enter nslookup dns.name.of.private.endpoint. The command-line utility outputs DNS details including the IP address registered with the DNS name. In our example, the IP address output matches the private address assigned to our endpoint.

Another way to test the endpoint is working as expected is by using Azure Storage Explorer that can be downloaded here.

Open Azure Storage Explorer, right-click Storage Accounts and then select Connect to Azure storage from the popup menu. Enter the connection string that can be copied from the Access Key blade of the storage account and then click on Connect.

We now have access to blob containers and the ability to create, browse, edit and delete.

When associating a resource and sub-resources to the endpoint, we selected Blob within the storage account. Due to the increased granularity that Private Endpoints offer when attempting to browses File Shares, Queues or Tables, access fails as expected.

For completeness, let’s run Azure Storage Explorer on a machine that’s not connected to the same virtual network. Now when attempting to connect to the storage account, this action fails with the following error message.

To learn more about Azure Private Link, head over to Microsoft docs: https://docs.microsoft.com/en-gb/azure/private-link/

Server 2008

Changing the Network Location of a Windows 2012 R2 Server Network Connection

It’s sometimes necessary to manually change the network location configuration of a Windows 2012 R2 Servers network connection. There are two common approaches to this, either by Local Group Policy or PowerShell. In this post I will be stepping through how to implement either method.

Windows classifies networks connections into one of three profiles, each profile configures the server with different firewall settings.

  • Private: Used for computers on a private or home network. This allows you to see computers and devices, while making your computer discoverable.
  • Public: Used for computers on a pubic network such as a coffee shop or internet café. Designed to keep your computer from being visible to other computers around you and to help protect your computer from any malicious software from the Internet.
  • Domain: Used for computers that belong to enterprise network.

By default new network connections are configured with the public profile, however, if ADDS (Active Directory Domain Services) are found on the network, the profile automatically changes to domain.

Changing the Network Location by Local Group Policy

1. Run gpedit.msc to open the Local Group Policy Editor

2. Navigate to Computer Configuration / Windows Settings / Security Settings / Network List Manager Policies and double click the appropriate Network Name

3. From the popup window select the Network Location tab, then select the correct location type

CNL03
4. Click OK and close the Local Group Policy Editor

CNL04
5. Finally checking back in the Network and Sharing Center, the network profile should now display the options chosen in the previous steps.

CNL05

Changing the Network Location by PowerShell

As with most things on Server 2012 it is possible to use PowerShell to change the network category. We first need to list the network connections and make note of the InterfaceIndex associated with the network connection we are looking to reconfigure.

1. Open an elevated PowerShell prompt and run the following CmdLet

Get-NetConnectionProfile

CNL06
2. Make note of the InterfaceIndex for the network connection that requires its location changing. We can then use the following command to change the connections network location type

Set-NetConnectionProfile -InterfaceIndex <ID> -NetworkCategory <Category>

For Example:

Set-NetConnectionProfule -InterfaceIndex 12 -NetworkCategory Private

CNL07
3. To confirm changes have been made, rerun the Get-NetConnectionProfile CmdLet and review the NetworkCategory reflects the change.

CNL08

Azure Networking

Test Network Speed and Latency to Azure

Just a quick post to mention one of the many Azure tools out there. This one in particular is for the network admin who have the need or are just interested in checking network connection speed and latencies to the Azure data centres.

TestLat001

http://azurespeed.com comes with a number of useful tests and is ideal during the project planning stage. For example, when planning to migrate a LOB application to Azure, which region would offer the best user experience.

Features include:

Latency Test
This test allows administrators to test network latency to Azure Storage in worldwide data centres.

CDN Test
This is currently unavailable do to attackers.

Upload Speed Test
This test makes it possible to checkout upload speeds to Azure Blob Storage located in different worldwide data centres.

Large File Upload Speed Test
This test allows administrators to test large file uploads to Azure Blob Storage, again in worldwide data centres, with additional upload options.

Download Speed Test
As the title suggests, this test monitors download speeds from different data centres when downloading a 100MB file.

Live Streaming Latency Test
Test latency from remote Azure Media Services live streaming.

Cloud Region Finder
Cloud Region Finder enables you to quickly lookup cloud and region information of application deployment, try it by entering url or ip address now! Currently Azure, AWS, AliCloud are supported.

Traffic Manager Test
Demonstrates the capability’s of Azure Traffic Manger.

Azure Online Tools available.
Additional Azure Online Tools.

A short but hopefully interesting post and well worth a quick visit! 🙂

Azure

Changing an Azure Virtual Network connection from site-to-site VPN to ExpressRoute

With more businesses becoming reliant on the cloud and on-premises datacenters being extended to Azure, ExpressRoute is becoming ever more popular. For customers that already have in place a site-to-site VPN, one of the first things to do after the ExpressRoute circuit has been previsioned is to switch the virtual network connection from a site-to-site VPN to the ExpressRoute circuit.

The following article works through the various steps involved in this process, including:

  • Checking the status of the ExpressRoute circuit
  • Updating the Virtual Network configuration
  • Linking ExpressRoute to the Virtual Network

NOTE: Migrating an existing virtual network from a site-to-site VPN to an ExpressRoute circuit will cause a short amount of lost connectivity between your on-premises network and your virtual network.

If like me you have access to multiple Azure subscriptions, the first thing to do is check you are in the right one. Using the cmdlet below we can pull back the details for the subscription that we are currently working in.

Get-AzureSubscription -Current

vpn2er01
To change subscriptions if required use:

Select-AzureSubscription -SubscriptionID "Subscription ID"

Once working in the correct subscription it is time to import the ExpressRoute PowerShell module. The module doesn’t load by default when PowerShell is run but it is found on the local drive and was installed by the Azure PowerShell installer.

To import the module run:

Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1'
Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\ExpressRoute\ExpressRoute.psd1'

vpn2er02

Checking the status of the ExpressRoute circuit

It is now possible to check that the ExpressRoute circuit has been provisioned correctly and is in the correct state. Use the Get-AzureDedicatedCircuit cmdlet to pull back information about the current circuits.

Before its possible to assign this circuit to a virtual network we need to make sure that the ServiceProviderProvisioningState is Provisioned and that the Status is Enabled. Once this is the case the circuit is ready!

vpn2er03

Updating the Virtual Network configuration

The first thing we need to do to is update the configuration of the virtual network gateway. To do this we need to first remove the current gateway which will then allow us to make configuration changes. This can be done via the portal and clicking on the Delete Gateway button or by using the Remove-AzureVNETGateway PowerShell cmdlet.

vpn2er04
The next step in configuring the virtual network involves resizing the existing gateway subnet. The site-to-site gateway supports a maximum size of a /29 subnet whereas the ExpressRoute gateway supports a minimum gateway subnet size of /28. As always this can be done either in the management portal or via PowerShell.

VPN2ExpressRoute006
After resizing the gateway subnet but before recreating a new gateway, we need to configure the virtual network for an ExpressRoute connection. To do this open the virtual network configuration tab and check the Use ExpressRoute checkbox in the management portal then click save.

VPN2ExpressRoute007
The final step in upgrading the virtual network configuration is to create a new Gateway. From within the management portal click the CREATE GATEWAY button to recreate the gateway.

VPN2ExpressRoute008
Once the gateway has completed provisioning, the final stage is to link the virtual network to your existing ExpressRoute circuit.

Linking ExpressRoute to the Virtual Network

At this point we can double check the ExpressRoute circuit is still in the correct state,  then finally link the circuit with the virtual network.

Get-AzureDedicatedCircuit

$Vnet = "VirtualNetwork-1"
$ServiceKey = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
New-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet

VPN2ExpressRoute009

A full listing of ExpressRoute PowerShell Cmdlets can be found in this Microsoft article Azure ExpressRoute PowerShell Cmdlets

That’s it for this post, hope its of some help 🙂

Azure

Using Network Security Groups in Azure to create a DMZ

More and more enterprises are extending their datacentre to the cloud and making use of these resources to deploy ever more complex solutions. As with on-premises infrastructure, it is quite often necessary to setup up different security zones in the cloud i.e. Trusted and DMZ.

On-premises we tend to deploy firewall appliances which are used to achieve this segmented networking infrastructure. However when deploying infrastructure to Azure, this option is not available to administrators. Microsoft Azure allows administrators to control the traffic in subnets using the Network Security Group (NSG) feature. Using an NSG makes it possible to create a subnet with restricted access from the other Azure subnets and also on-premises network.

Network security groups give the ability to configure rules and control inbound and outbound network traffic that can then be assigned to a single VM or a whole subnet and all the VMs within it.

The main reason I have used NSGs has been when deploying ADFS to Azure. A typical deployment has two domain controllers, two ADFS servers and single ADSync server in a trusted subnet and then two WAP servers in the DMZ subnet.

For example:

Azure NSG

Configuring Network Security Groups is currently via Azure PowerShell as shown below.

Deploying a Network Security Group:

The first thing to do when deploying a Network Security Group is to create a default NSG. Use the PowerShell command below giving it a name, location and a label for the NSG.

New-AzureNetworkSecurityGroup -Name "WAP-HTTPS" -Location "North Europe" -Label "Security group for DMZ Subnet"

Once the NSG has been created we can display the default rules that have been associated with it.

View the NSG details:

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" -Detailed

NSG4DMZ001

The next step is to add any inbound rules to the NSG that we require. That is inbound traffic to the subnet that the NSG will be assigned to later. In this example it is inbound traffic to the subnet that will be used as the DMZ and house the WAP servers. These rules are not limited to allow but also deny rules.

Create Inbound NSG Rules:

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound RDP from ALL Internal Networks" -Type Inbound -Priority 101 -Action Allow -SourceAddressPrefix 'VIRTUAL_NETWORK'  -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '3389' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound HTTPS from Internet" -Type Inbound -Priority 110 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix "DMZ Subnet" -DestinationPortRange '443' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound RDP from Internet" -Type Inbound -Priority 111 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix "DMZ Subnet" -DestinationPortRange '3389' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Deny Inbound traffic to Trusted Subnet" -Type Inbound -Priority 200 -Action Deny -SourceAddressPrefix 'VIRTUAL_NETWORK'  -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '*' -Protocol '*'

Once all the inbound rules have been created its time to add outbound rules. Again this is outbound traffic from the subnet being used as the DMZ in this example.

Create Outbound Rules:

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Outbound HTTPS from DMZ Subnet" -Type Outbound -Priority 100 -Action Allow -SourceAddressPrefix 'VIRTUAL_NETWORK'  -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '443' -Protocol TCP

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Deny Outbound traffic from DMZ Subnet" -Type Outbound -Priority 200 -Action Deny -SourceAddressPrefix 'VIRTUAL_NETWORK'  -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '*' -Protocol '*'

Once again at this stage we can use the ‘Get-AzureNetworkSecurityGroup’ cmdlet with the -Detailed switch as above to get a screen output of the rules now configured in the NSG.

NSG4DMZ002

The final step to the configuration is to assign the NSG to our DMZ subnet. This subnet is where the inbound and outbound rules will apply once the NSG has bound to the subnet.

Add the SG to the backend subnet:

Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName "vNET" -SubnetName "DMZ Subnet"

NOTE: When making changes to an NSG, if they don’t appear to take effect immediately, allow plenty of time before making any further changes. It’s my experience that people can change good configuration, assuming what they have configured is not working.