Practical recipes to manage network trafc in Azure, optimise performance and

secure Azure resources

Mustafa Toroman

www.packt.com

Azure

Networking

Cookbook

Azure Networking Cookbook

Practical recipes to manage network tra󰀩c in Azure,

optimise performance and secure Azure resources

Mustafa Toroman

BIRMINGHAM – MUMBAI

Azure Networking Cookbook

or transmitted in any form or by any means, without the prior written permission of the

publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the

information presented. However, the information contained in this book is sold without

warranty, either express or implied. Neither the author, nor Packt Publishing or its

dealers and distributors, will be held liable for any damages caused or alleged to have

been caused directly or indirectly by this book.

Packt Publishing has endeavoured to provide trademark information about all of the

companies and products mentioned in this book by the appropriate use of capitals.

However, Packt Publishing cannot guarantee the accuracy of this information.

Commissioning Editor: Vijin Boricha

Acquisition Editor: Shrilekha Inan

Content Development Editor: Ronn Kurien

Technical Editor: Pratik Shet

Copy Editor: Sas Editing

Project Co-ordinator: Jagdish Prabhu

Proofreader: Sas Editing

Indexer: Tejal Daruwale Soni

Graphics: Tom Scaria

Production Co-ordinator: Saili Kale

First published: March 2019

Production reference: 1290319

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham B3 2PB, UK.

ISBN 978-1-78980-022-7

www.packtpub.com

https://mapt/io/

Subscribe to our online digital library for full access to over 7,000 books and videos,

as well as industry leading tools to help you plan your personal development and

advance your career. For more information, please visit our website.

Why subscribe?

• Spend less time learning and more time coding with practical eBooks and

Videos from over 4,000 industry professionals

• Improve your learning with Skill Plans built especially for you

• Get a free eBook or video every month

• Mapt is fully searchable

• Copy and paste, print and bookmark content

Packt.com

Did you know that Packt offers eBook versions of every book published, with PDF

and ePub les available? You can upgrade to the eBook version at www.Packt.com

and as a print book customer, you are entitled to a discount on the eBook copy. Get

in touch with us at customercare@packtpub.com for more details.

At www.Packt.com, you can also read a collection of free technical articles, sign up

for a range of free newsletters and receive exclusive discounts and offers on Packt

books and eBooks.

Contributors

About the author

Mustafa Toroman is a program architect and senior system engineer with

Authority Partners. With years of experience of designing and monitoring

infrastructure solutions, lately, he focuses on designing new solutions in the cloud

and migrating existing solutions to the cloud. He is very interested in DevOps

processes, and he’s also an Infrastructure-as-Code enthusiast. Mustafa has over 30

Microsoft certications and has been an MCT for the last six years. He often speaks

at international conferences about cloud technologies, and has been awarded the

MVP award for Microsoft Azure for the last three years in a row.

Mustafa also authored Hands-On Cloud Administration in Azure and co-authored Learn

Node.js with Azure, both published by Packt.

About the reviewer

Kapil Bansal is a technical consultant at HCL Technologies in India. He has more

than eleven years of experience in the IT industry. He has worked on Microsoft

Azure (PaaS, IaaS, Kubernetes and DevOps), ALM, ITIL and Six Sigma. He provides

technical supervision and guidance during client engagement sessions. His expertise

includes strategic design and architectural mentorship, assessments, POCs, sales

life cycles and consulting on engagement processes. He has worked with companies

such as IBM India Pvt Ltd., NIIT Technologies, Encore Capital Group and Xavient

Software Solutions, and he has served clients based in the United States, the United

Kingdom, India and Africa, including T-Mobile, WBMI, Encore Capital and Airtel.

Packt is Searching for Authors Like You

If you’re interested in becoming an author for Packt, please visit authors.

packtpub.com and apply today. We have worked with thousands of developers and

tech professionals, just like you, to help them share their insight with the global tech

community. You can make a general application, apply for a specic hot topic that

we are recruiting an author for, or submit your own idea.

[ i ]

Table of Contents

Preface xi

Chapter 1: Azure Virtual Network 1

Technical requirements 1

Creating a virtual network in the Azure portal 2

Getting ready 2

How to do it... 2

How it works... 4

Creating a virtual network with PowerShell 4

Getting ready 4

How to do it... 5

How it works... 5

Adding a subnet in the Azure portal 5

Getting ready 5

How to do it... 6

How it works... 8

Adding a subnet with PowerShell 8

Getting ready 8

How to do it... 9

How it works... 9

There’s more... 9

Changing the address space size 10

Getting ready 10

How to do it... 10

How it works... 11

Changing a subnet’s size 11

Getting ready 11

How to do it... 11

How it works... 13

Table of Contents

[ ii ]

Chapter 2: Virtual Machine Networking 15

Technical requirements 15

Creating Azure VMs 15

Getting ready 15

How to do it... 16

How it works... 21

See also

If you are interested to nd out more about Azure VMs, you can read my book,

Hands-On Cloud Administration in Azure, from Packt Publishing, where VMs are

covered in more detail.

Virtual Machine Networking

[ 22 ]

Viewing VM network settings

After an Azure VM is created, we can review the network settings in the VM blade.

Getting ready

Before you start, open a web browser and go to the Azure portal at

https://portal.azure.com. Here, locate the previously created VM.

How to do it...

In order to review the VM network settings, we must do the following steps:

1. In the VM blade, locate the Networking settings. Here, you can see Network

interface, APPLICATION SECURITY GROUPS and Network security

group associated with the VM. An example of this is shown in the following

screenshot:

2. If we select any of the associated network elements, we can discover more

details. For example, if we select the Network interface option associated

with the VM, we can see other networking information such as Private IP

address, Virtual network/subnet, Public IP address, Network security

group, IP congurations and DNS servers. The NIC view is shown in

the following screenshot:

Chapter 2

[ 23 ]

How it works...

Networking information is displayed in several places, including in the VM’s

network settings. Additionally, each Azure resource has a separate blade and exists

as an individual resource, so we can view these settings in multiple places. However,

the most complete picture about VM network settings we can nd is in the VM blade

and NIC blade.

Creating a new network interface

An NIC is usually created during the VM creation process, but each VM can have

multiple NICs. Based on this, we can create an NIC as an individual resource and

attach it or detach it as needed.

Getting ready

Before you start, open a web browser and go to the Azure portal at

https://portal.azure.com.

Virtual Machine Networking

[ 24 ]

How to do it...

In order to create a new NIC using the Azure portal, follow these steps:

1. In the Azure portal, select Create a resource and choose Network interface

under Networking (or search for network interface in the search bar).

2. In the creation blade, we need to provide information relating to the

Name, Virtual network and Subnet that the NIC will be associated with.

Other information to be provided includes the IP address assignment type

(Dynamic or Static), whether we want the NIC to be associated with a

Network security group type and whether we want to use IPv6. All Azure

resources require information on the Subscription, Resource group and

Location and NICs are no exception. The information needed to create

a new NIC is shown in the following screenshot:

Chapter 2

[ 25 ]

How it works...

An NIC can’t exist without network association, and this association must be

assigned to a virtual network and subnet. This is dened during the creation

process and cannot be changed later. On the other hand, association with a VM

can be changed and the NIC can be attached or detached from a VM at any time.

Attaching a network interface to a VM

Each VM can have multiple NICs. Because of this, we can add a new NIC at any time.

Getting ready

Before you start, open a web browser and go to the Azure portal at

https://portal.azure.com. Here, locate the previously created VM.

How to do it...

To attach a NIC to a VM, we must do the following:

1. In the VM blade, make sure the VM is stopped (that is, deallocated).

2. Locate the Networking settings in the VM blade.

3. At the top of the Networking settings screen in the VM blade, select the

Attach network interface option.

4. A new option will appear, allowing you to create a new NIC or select an

already-existing NIC that is not associated with the VM.

5. Click OK and, in a few moments, the process will nish and the NIC will

be associated with the VM. An example of this is shown in the following

screenshot:

Virtual Machine Networking

[ 26 ]

How it works...

Each VM can have multiple NICs. The number of NICs associated with a VM

depends on the type and size of the VM. To attach an NIC to a VM, the VM needs to

be stopped (that is, deallocated); you can’t add an additional NIC to a running VM.

Detaching a network interface from a VM

Just as with attaching a NIC, we can detach NIC at any time and attach it to

another VM.

Getting ready

Before you start, open a web browser and got to the Azure portal at https://

portal.azure.com. Here, locate the previously created VM.

How to do it...

To detach a network interface from a VM, we must do the following:

1. In the VM blade, make sure the VM is stopped (that is, deallocated).

2. Locate the Networking settings in the VM blade.

3. At the top of the Networking settings screen in the VM blade, select the

option to Detach network interface.

4. Select the NIC you want to detach from the VM.

5. Click OK and, in a few moments, the process will nish and the NIC will

be removed from the VM. An example of this is shown in the following

screenshot:

Chapter 2

[ 27 ]

How it works...

To detach a NIC, the VM associated with the NIC must be stopped (that is,

deallocated). At least one NIC must be associated with the VM; so, you can’t

remove the last NIC from a VM. All network associations stay with the NIC;

they are assigned to the NIC, not to the VM.

[ 29 ]

Network Security Groups

Network Security Groups (NSGs) contain sets of rules that allow or deny specic

trafc access to specic resources or subnets in Azure. An NSG can be associated

with either a subnet (by applying security rules to all resources associated with the

subnet) or a network interface (NIC) (by applying security rules only to the virtual

machine (VM) associated with the NIC).

We will cover the following recipes in this chapter:

• Creating a new NSG in the Azure portal

• Creating a new NSG with PowerShell

• Creating a new allow rule in NSG

• Creating a new deny rule in NSG

• Creating a new NSG rule with PowerShell

• Assigning an NSG to a subnet

• Assigning an NSG to a network interface

• Assigning an NSG with PowerShell

• Creating an Application Security Group (ASG)

• Associating an ASG with a VM

• Creating rules with an NSG and an ASG

Technical requirements

For this chapter, the following is required:

• An Azure subscription

• Azure PowerShell

Code examples can be found at https://github.com/PacktPublishing/Azure-

Networking-Cookbook/tree/master/Chapter03.

Network Security Groups

[ 30 ]

Creating a new NSG in the Azure portal

As a rst step to controlling network trafc better, we are going to create a new NSG.

NSGs are built-in tools for network control and allow us to control incoming and

outgoing trafc on a network interface or at the subnet level.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To create a new NSG using the Azure portal, we must follow these steps:

1. In the Azure portal, select Create a resource and choose Network security

group under the Networking services (or search for network security

group in the search bar).

2. The parameters we need to dene for the deployment are Name,

Subscription, Resource group and Location. An example of the

required parameters is shown in the following screenshot:

3. After the deployment has been validated and started (it takes a few moments

to complete), the NSG is ready for use.

Chapter 3

[ 31 ]

How it works...

The NSG deployment can be initiated during VM deployment. This will associate

the NSG with the NIC associated with the VM. In this case, the NSG is already

associated with the resource, and rules dened in the NSG will apply only to the

associated VM.

If the NSG is deployed separately, as in this recipe, it is not associated and the rules

that are created are not applied until the association has been created with the NIC

or the subnet. When it is associated with a subnet, the NSG rules will apply to all

resources on the subnet.

Creating a new NSG with PowerShell

Alternatively, we can create an NSG using Azure PowerShell. The advantage of this

approach is that we can add NSG rules in a single script, creating custom rules right

after the NSG is created. This allows us to automate the deployment process and

have our own default rules right after the NSG has been created.

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

How to do it...

To deploy a new NSG, execute the following command:

New-AzureRmNetworkSecurityGroup -Name "nsg1" -ResourceGroupName "Packt-

Networking-Script" -Location "westeurope"

How it works...

The nal outcome will be the same as creating a new NSG using the Azure portal:

a new NSG will have been created with default rules. An advantage of using

PowerShell is that we can add additional rules and automate the process. We will

see an example of this in the Creating a new NSG rule with PowerShell recipe later in

this chapter.

Network Security Groups

[ 32 ]

Creating a new allow rule in NSG

When a new NSG is created, only the default rules are present. Default rules allow

all outbound trafc and block all inbound trafc. To change these, additional rules

need to be created. First, we are going to show you how to create a new rule to allow

inbound trafc.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com. Locate the previously created NSG.

How to do it...

To create a new NSG allow rule using the Azure portal, we must follow these steps:

1. In the NSG blade, locate the Inbound security rules option under Settings.

2. Click on the Add button at the top of the page and wait for the new blade

to open:

Chapter 3

[ 33 ]

3. In the new blade, we need to provide information for the Source (location

and port), Destination (location and port), Protocol, Action, Priority, Name

and Description elds. If you want to allow trafc, make sure you select

Allow for Action. An example of how to create a rule to allow trafc over

port 443 (thus allowing trafc to the web server) is shown in the following

screenshot:

Network Security Groups

[ 34 ]

How it works...

By default, all trafc coming from Azure Load Balancer or Azure Virtual Network

is allowed. All trafc coming over the internet is denied. To change this, we need

to create additional rules. Make sure you set the right priority when creating

rules. Rules with highest priority (that is, the ones with the lower number) are

processed rst, so if you have two rules, with one denying trafc and one allowing

it, the one with higher priority will take precedence, while one with lower priority

will be ignored.

Creating a new deny rule in NSG

When a new NSG is created, only default rules are present. Default rules allow all

outbound trafc and block all inbound trafc. To change this, additional rules need

to be created. Now, we are going to show you how to create a new outbound rule to

deny trafc.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com. Locate the previously created NSG.

How to do it...

To create a new NSG deny rule using the Azure portal, we must follow these steps:

1. In the NSG blade, locate the Outbound security rules option under Settings.

2. Click on the Add button at the top of the page and wait for the new blade

to open:

Chapter 3

[ 35 ]

3. In the new blade, we need to provide information for Source (location

and port), Destination (location and port), Protocol, Action, Priority,

Name and Description. If you want to deny trafc, make sure you select

Deny for Action. An example of how to create a rule to deny trafc over

port 22 is shown in the following screenshot:

Network Security Groups

[ 36 ]

How it works...

All outbound trafc is allowed by default, regardless of where it is going. If we want

to explicitly deny trafc over a specic port, we need to create a rule to do so. Make

sure you set the priority right when creating rules. Rules with the highest priority

(the ones with the lower number) are processed rst, so if you have two rules, with

one denying trafc and one allowing it, the rule with higher priority will apply.

Creating a new NSG rule with PowerShell

Alternatively, we can create an NSG rule using Azure PowerShell. This command

can be executed right after the NSG has been created, allowing us to create and

congure an NSG in a single script. This way, we can standardise deployment

and have rules applied each time an NSG is created.

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

How to do it...

To create a new NSG rule, execute the following command:

$nsg = Get-AzureRmNetworkSecurityGroup -Name 'nsg1' -ResourceGroupName

'Packt-Networking-Script'

$nsg | Add-AzureRmNetworkSecurityRuleConfig -Name 'Allow_HTTPS'

-Description 'Allow_HTTPS' -Access Allow -Protocol Tcp -Direction

Inbound -Priority 100 -SourceAddressPrefix Internet -SourcePortRange

* -DestinationAddressPrefix * -DestinationPortRange 443 | Set-

AzureRmNetworkSecurityGroup

Chapter 3

[ 37 ]

How it works...

Using a script, creating an NSG rule is just a matter of parameters. The Access

parameter, which can be either Allow or Deny, will determine whether we want to

allow trafc or deny it. The direction parameter, which can be inbound or outbound,

determines whether the rule is for inbound or outbound trafc. All other parameters

are the same, no matter what kind of rule we want to create. Again, priority plays

a very important role, so we must make sure it’s chosen correctly.

There’s more...

As mentioned in the Creating a new NSG with PowerShell recipe, we can create the

NSG and the rules that are needed in a single script. The following script is an

example of this:

$nsg = New-AzureRmNetworkSecurityGroup -Name 'nsg1' -ResourceGroupName

'Packt-Networking-Script' -Location "westeurope"

$nsg | Add-AzureRmNetworkSecurityRuleConfig -Name 'Allow_HTTPS'

-Description 'Allow_HTTPS' -Access Allow -Protocol Tcp -Direction

Inbound -Priority 100 -SourceAddressPrefix Internet -SourcePortRange

* -DestinationAddressPrefix * -DestinationPortRange 443 | Set-

AzureRmNetworkSecurityGroup

Assigning an NSG to a subnet

The NSG and rules must be assigned to a resource to make any impact. First, we are

going to show you how to associate an NSG with a subnet.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com. Locate the previously created NSG.

Network Security Groups

[ 38 ]

How to do it...

To assign an NSG to a subnet, we must follow these steps:

1. In the NSG blade, locate the Subnets option under Settings.

2. Click on the Associate button at the top of the page and wait for the new

blade to open:

Chapter 3

[ 39 ]

3. In the new blade, rst select Virtual network, which contains the subnet you

want to associate the NSG with:

4. After selecting the virtual network, select the Subnet you want to associate

it with:

Network Security Groups

[ 40 ]

5. After submitting the change, the subnet will appear in the list of associated

subnets:

How it works...

When an NSG is associated with a subnet, the rules in the NSG will apply to all of

the resources in the subnet. Note that the subnet can be associated with more than

one NSG, and the rules from all the NSGs will apply in that case. Priority is the most

important factor when looking at a single NSG, but when the rules from more NSGs

are observed, the Deny rule will prevail. So, if we have two subnets, one with Allow

on port 443 and another one with the Deny rule on the same port, trafc on this port

will be denied.

Assigning an NSG to a network interface

An NSG and its rules must be assigned to a resource to make any impact. Now, we

are going to show you how to associate an NSG with a network interface.

Chapter 3

[ 41 ]

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com. Locate the previously created NSG.

How to do it...

To assign an NSG to a network interface, we must follow these steps:

1. In the NSG blade, locate the Network interfaces option under Settings.

2. Click on the Associate button at the top of the page and wait for the new

blade to open:

Network Security Groups

[ 42 ]

3. Select the NIC you want to associate it with from the list of those available:

Chapter 3

[ 43 ]

How it works...

When an NSG is associated with an NIC, the NSG rules will apply only to a single

NIC (or a VM associated with the NIC). The NIC can be associated with only one

NSG directly, but a subnet associated with an NIC can be associated with another

NSG (or even multiple NSGs). This is similar to when we have more NSGs in a single

subnet, and the Deny rule will take higher priority. If either of the NSGs allows trafc

on a port, but another NSG is blocking it, trafc will be denied.

Assigning an NSG with PowerShell

Alternatively, we can associate an NSG using Azure PowerShell. In this recipe, we

are going to show you how to associate an NSG with a subnet.

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

How to do it...

To associate an NSG with a subnet, execute the following command:

$vnet = Get-AzureRmVirtualNetwork -Name 'Packt-Script' -ResourceGroupName

'Packt-Networking-Script'

$subnet = Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet

-Name BackEnd

$nsg = Get-AzureRmNetworkSecurityGroup -ResourceGroupName 'Packt-

Networking-Script' -Name 'nsg1'

$subnet.NetworkSecurityGroup = $nsg

Set-AzureRmVirtualNetwork -VirtualNetwork $vnet

How it works...

Using PowerShell, we need to collect information on the virtual network, subnet and

NSG. When all of the information is gathered, we can perform the association using

Set-AzureRmVirtualNetwork and apply changes.

Network Security Groups

[ 44 ]

Creating an Application Security Group

(ASG)

ASGs are an extension of NSGs, allowing us to create additional rules and take

better control of trafc. Using only NSGs allows us to create rules that will allow

trafc only for a specic source, IP address or subnet. ASGs allow us to create

better ltering and create additional checks on which trafc is allowed.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To create an ASG using the Azure portal, we must follow these steps:

1. In the Azure portal, select Create a resource and choose Application security

group under the Networking services (or search for application security

group in the search bar).

2. The parameters we need to dene for deployment are Subscription,

Resource group, Name and Region. An example of the required parameters

is shown in the following screenshot:

Chapter 3

[ 45 ]

How it works...

ASGs don’t make much difference on their own, and must be combined with NSGs

to create NSG rules that will allow for better control of trafc, applying additional

checks before trafc ow is allowed.

Associating an ASG with a VM

After creating an ASG, we must associate it with a VM. After this is completed, we

can create rules with the NSG and ASG for trafc control.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com. Locate the previously created virtual machine.

How to do it...

To associate an ASG with a virtual machine, we must follow these steps:

1. In the virtual machine blade, locate the Networking settings.

2. In the Networking settings, select the Congure the application security

groups option, as shown in the following screenshot:

Network Security Groups

[ 46 ]

3. In the new blade from the list of available ASGs, select the ASG that you

want to associate the VM with:

4. After clicking Save, it takes a few seconds applying the changes until the VM

is associated with the ASG.

How it works...

The VM must be associated with the ASG. We can associate more than one VM

with each ASG. The ASG is then used in combination with the NSG to create new

NSG rules.

Creating rules with an NSG and an ASG

As a nal step, we can use NSGs and ASGs to create new rules with better control.

This approach allows us to have better control of trafc, limiting incoming trafc not

only to a specic subnet, but also only based on whether or not the resource is part of

the ASG.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com. Locate the previously created NSG.

Chapter 3

[ 47 ]

How to do it...

To create a rule using both an ASG and an NSG, we must follow these steps:

1. In the NSG blade, nd Inbound security rules. Select Add to add a new rule.

2. For the source, select Application Security Group, and then select the

ASG you want to use as the source. We also need to provide parameters

for Source, Source port ranges, Destination, Destination port ranges,

Protocol, Action, Priority and Name. An example is shown in the

following screenshot:

Network Security Groups

[ 48 ]

How it works...

Using only NSGs to create rules, we can create allow or deny trafc for a specic

IP address or range. With an ASG, we can widen or narrow this as needed. For

example, we can create a rule to allow VMs from a frontend subnet, but only if

these VMs are in a specic ASG. Alternatively, we can allow access to a number

of VMs from different virtual networks and subnets, but only if they belong to

a specic ASG.

[ 49 ]

Managing IP Addresses

In Azure, we can have two types of IP addresses, private and public. Public

addresses can be accessed over the internet. Private addresses are from the Azure

Virtual Network address space and are used for private communication on private

networks. Addresses can be assigned to a resource or exist as a separate resource.

We will cover the following recipes in this chapter:

• Creating a new public IP address in the portal

• Creating a new public IP address with PowerShell

• Assigning a public IP address

• Unassigning a public IP address

• Creating a reservation for a public IP address

• Removing a reservation for a public IP address

• Creating a reservation for a private IP address

• Changing a reservation for a private IP address

• Removing a reservation for a private IP address

Managing IP Addresses

[ 50 ]

Technical requirements

For this chapter, the following is required:

• An Azure subscription

• Azure PowerShell

Code samples can be found at https://github.com/PacktPublishing/Azure-

Networking-Cookbook/tree/master/Chapter04.

Creating a new public IP address in the

portal

Public IP addresses can be created as a separate resource or during the creation of

some other resources (a virtual machine (VM), for example). Therefore, the public

IP can exist as part of a resource, or as a standalone resource of its own. First, we

are going to show you how to create a new public IP address.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To create a new public IP address, we must follow these steps:

1. In the Azure portal, select Create a resource and choose Public IP address

under the Networking services (or search for public IP address in the

search bar).

2. The parameters we need to dene for deployment are Name, SKU, IP

Version, IP address assignment, DNS name label, Subscription, Resource

group and Location. An example of the required parameters is shown in the

following screenshot:

Chapter 4

[ 51 ]

How it works...

The stock keeping unit (SKU) can be either Basic or Standard. The main difference

is that Standard is closed to inbound trafc by default (inbound trafc must be

whitelisted in Network Security Groups (NSGs)) and Standard is zone-redundant.

Another difference is that a standard SKU public IP address has a static assignment,

while a basic SKU can be either static or dynamic.

You can choose either the IPv4 or IPv6 version for the IP address, but choosing IPv6

will limit you to a dynamic assignment.

Managing IP Addresses

[ 52 ]

The DNS name label is optional; it can be used to resolve the endpoint in case a

dynamic assignment is selected. Otherwise, there is no point in creating a DNS

label, as an IP address can always be used to resolve the endpoint in case a static

assignment is selected.

Creating a new public IP address with

PowerShell

Alternatively, we can create a public IP address using Azure PowerShell. Again, this

approach is better when we want to automate the process. Even a public IP address

can exist on its own; it’s usually created to be joined with other resources and to be

used as an endpoint. When using PowerShell to create a resource, we can continue

to the next step and join it with a resource in a single script.

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

How to do it...

To deploy a new public IP address, execute the following command:

New-AzureRmPublicIpAddress -Name 'ip-public-script' -ResourceGroupName

'Packt-Networking-Script' -AllocationMethod Dynamic -Location

'westeurope'

How it works...

As an outcome, a new public IP address will be created. The settings in this case

will be a basic SKU dynamic assignment, IPv4 version and without a DNS label.

Furthermore, we can use additional switches such as -SKU, -IPAddressVersion

or -DomainNamelabel to dene these options if needed.

Assigning a public IP address

A public IP address can be created as a separate resource, or can be unassigned from

another resource and exist on its own. Such an IP address can then be assigned to a

new or another already-existing resource. If the resource is no longer in use or has

been migrated, we can still use the same public IP address.

Chapter 4

[ 53 ]

In this case, the public endpoint that’s used to access a service may stay unchanged.

This can be useful when a publicly available application or service is migrated or

upgraded, as we can keep using the same endpoint and end users don’t need to

be aware of any change.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To assign a public IP address, we must do the following:

1. Locate the network interface (NIC) that you want the IP address to be

assigned to. This can be done directly by nding the NIC, or through the

VM blade that the NIC is assigned to.

2. In the NIC blade, go to IP congurations under Settings, and select the

conguration shown in the following screenshot:

Managing IP Addresses

[ 54 ]

3. In the new blade, select to enable Public IP address and select the public IP

address that you want to assign. Only unassigned IP addresses in the same

region will show in the list. An example of this is shown in the following

screenshot:

4. After the public IP address has been selected, click Save to apply the settings.

How it works...

A public IP address exists as a separate resource and can be assigned to a resource

at any time. When a public IP address is assigned, you can use this IP address to

access services running on a resource that the IP address is assigned to (remember

that an appropriate NSG must be applied). We can also remove an IP address from

a resource and assign it to a new resource. For example, if we want to migrate

services to a new VM, the IP address can be removed from the old VM and assigned

to the new one. This way, service endpoints running on the VM will not change.

This is especially useful when static IP addresses are used.

Chapter 4

[ 55 ]

Unassigning a public IP address

A public IP address can be unassigned from a resource in order to be saved for later

use, or assigned to another resource. When a resource is deleted or decommissioned,

we can still put the public IP address to use and assign it to the next resource.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com. Make sure that the VM using a public

IP address is not running.

How to do it...

1. Locate the NIC that the public IP address is associated with.

2. In the NIC blade, go to IP congurations under Settings and select the IP

conguration:

Managing IP Addresses

[ 56 ]

3. In the new blade, set Public IP address to Disabled:

4. After the changes are made, click Save to apply the new conguration.

How it works...

A public IP address can be assigned or unassigned from a resource in order to save

it for future use or to transfer it to a new resource. To remove it, we simply disable

the public IP address in the IP conguration under the NIC that the IP address is

assigned to. This will remove the association, but keep the IP address as a separate

resource.

Creating a reservation for a public IP

address

The default option for a public IP address is dynamic IP assignment. This can

be changed during the public IP address creation, or later. If this is changed

from dynamic, then the public IP address becomes reserved (or static).

Chapter 4

[ 57 ]

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To create a reservation for a public IP address, follow these steps:

1. Locate the public IP address in the Azure portal. This can be done by nding

the IP address directly, or through the resource it’s assigned to (either the

NIC or VM).

2. In the IP address blade, go to Conguration under Settings. Change

Assignment from Dynamic to Static, as shown in the following screenshot:

3. After this change has been made, click Save to apply the new settings.

Managing IP Addresses

[ 58 ]

How it works...

A public IP address is set to dynamic by default. This means that an IP address might

change in time. For example, if a VM that an IP address is assigned to is turned off

or rebooted, there is a possibility that the IP address will change after the VM is up

and running again. This can cause issues if services that are running on the VM are

accessed over the public IP address, or if there is a DNS record associated with the

public IP address.

We create an IP reservation and set the assignment to static to avoid such a scenario

and keep the IP address reserved for our services.

Removing a reservation for a public IP

address

If the public IP address is set to static, we can remove a reservation and set the IP

address assignment to dynamic. This isn’t done often as there is usually a reason

why the reservation is set in the rst place. But as the reservation for the public IP

address has an additional cost, there is sometimes a need to remove the reservation

if it is not necessary.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com. Make sure that the IP address is not

associated with any resource.

How to do it...

To remove a reservation for a public IP address, follow these steps:

1. Locate the Public IP address in the Azure portal.

2. In the Public IP address blade, go to Conguration under Settings and set

Assignment to Dynamic:

Chapter 4

[ 59 ]

3. After these changes have been made, click Save to apply the new

conguration

How it works...

To remove an IP reservation from a public IP address, the public IP address must

not be associated with a resource. We can remove the reservation by setting the IP

address assignment to dynamic.

The main reason for this is pricing. In Azure, the rst ve public IP reservations are

free. After the initial ve, each new reservation is billed. To avoid paying anything

unnecessary, we can remove a reservation when it is not needed or when the public

IP address is not being used.

Managing IP Addresses

[ 60 ]

Creating a reservation for a private

IP address

Similar to public IP addresses, we can make a reservation for private IP addresses.

This is usually done to ensure communication between servers on the same virtual

network and to allow for the usage of IP addresses in connection strings.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To create a reservation for a private IP address, follow these steps:

1. In the Azure portal, locate the NIC you want to make the reservation for.

2. In the NIC blade, go to IP congurations under Settings and select the

IP conguration:

3. In the new blade, under Private IP address settings, set Assignment to Static.

4. The current IP address value will be set automatically. If needed, you can

change that value to another value, but it must be in the address space of

the subnet associated with the NIC:

Chapter 4

[ 61 ]

5. After these changes have been made, click Save to apply the new

conguration.

How it works...

A reservation for an IP address can be made for private IP addresses. The difference

is that a private IP address does not exist as a separate resource, but is assigned to

an NIC.

Another difference is that you can select a value for a private IP address. A public

IP address is assigned randomly and can be reserved, but you cannot choose which

value this will be. For private IP addresses, you can select the value for the IP, but it

must be an unused IP from the subnet associated with the NIC.

Managing IP Addresses

[ 62 ]

Changing a reservation for a private

IP address

For private IP addresses, you can change an IP address at any time to another value.

With public IP addresses, this isn’t the case, as you get the IP address randomly from

a pool and aren’t able to change the value of public IP addresses. With a private IP

address, you can change the value to another IP address from the address space.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To change a reservation for a private IP address, follow these steps:

1. In the Azure portal, locate the NIC you want to make changes for.

2. In the NIC blade, go to IP congurations under Settings and select the

IP conguration:

Chapter 4

[ 63 ]

3. In Private IP address settings, enter a new value for the IP address:

4. After these changes have been made, click Save to apply the new

conguration.

How it works...

A reservation for a private IP address can be changed. Again, the value must be an

unused IP address from a subnet associated with the NIC. If the VM associated with

the NIC is turned off, the new IP address will be assigned on its next start-up. If the

VM is running, it will be restarted to apply new changes.

Managing IP Addresses

[ 64 ]

Removing a reservation for a private

IP address

Similar to public IP addresses, we can remove a reservation at any time. A private

IP address is free, so additional costs aren’t a factor in this case. But there are

scenarios where a dynamic assignment is required, and we can set it at any time.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To remove a reservation for a private IP address, follow these steps:

1. In the Azure portal, locate the NIC you want to make changes to.

2. In the NIC blade, go to IP congurations under Settings and select the

IP conguration:

Chapter 4

[ 65 ]

3. In the new blade, under Private IP address settings, change Assignment

to Dynamic:

4. After these changes have been made, click Save to apply the new

conguration.

How it works...

We can remove a private IP address reservation at any time by switching the

Assignment to Dynamic. When this change is made, the VM associated with the

NIC will be restarted to apply the new changes. After a change is made, a private

IP address may change after the VM is restarted or turned off.

[ 67 ]

Local and Virtual

Network Gateways

Local and virtual network gateways are virtual private network (VPN) gateways

that are used to connect to on-premises networks and encrypt all trafc going

between Azure Virtual Network (VNet) and a local network. Each virtual network

can have only one virtual network gateway, but one virtual network gateway can be

used to congure multiple VPN connections.

We will cover the following recipes in this chapter:

• Creating a local network gateway in the Azure portal

• Creating a local network gateway with PowerShell

• Creating a virtual network gateway in the Azure portal

• Creating a virtual network gateway with PowerShell

• Modifying the local network gateway settings

Technical requirements

For this chapter, the following is required:

• An Azure subscription

• Azure PowerShell

Code examples can be found in https://github.com/PacktPublishing/Azure-

Networking-Cookbook/tree/master/Chapter05.

Local and Virtual Network Gateways

[ 68 ]

Creating a local network gateway in the

Azure portal

Although a local network gateway is created in Azure, it represents your local

(on-premises) network and holds conguration information on your local network

settings. It’s an essential component for creating the VPN connection that is needed

to create a Site-to-Site connection between the Azure VNet and the local network.

Getting ready

Before you start, open a web browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to create a new local network gateway, the following steps are required:

1. In the Azure portal, select Create a resource and choose Local network

gateway under the Networking services (or search for local network

gateway in the search bar).

2. The parameters that we need to provide are Name, IP address (that is, the

public IP address of the local rewall), Address space (the local address space

that you want to connect to), Subscription, Resource group and Location.

Optionally, we can congure Border Gateway Protocol (BGP) settings:

Chapter 5

[ 69 ]

How it works...

The local network gateway is used to connect a virtual network gateway to an on-

premises network. The virtual network gateway is directly connected to the virtual

network and has all the relevant Azure VNet information needed to create a VPN

connection. On the other hand, a local network gateway holds all the local network

information needed to create a VPN connection.

Creating a local network gateway with

PowerShell

As mentioned in the previous recipe, the local network gateway holds information

on the local network that we want to connect to Azure VNet. In addition to creating

a local network gateway through the Azure portal, we can create it with Azure

PowerShell.

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

How to do it...

To create a new local network gateway, execute the following command:

New-AzureRmLocalNetworkGateway -Name packt-lng-script -ResourceGroupName

'Packt-Networking-Script' -Location 'westeurope' -GatewayIpAddress

'195.222.10.20' -AddressPrefix '192.168.1.0/24'

How it works...

In order to deploy a new local network gateway, we need to provide parameters for

the name, resource group, location, gateway IP address and address prex that we

want. The gateway IP address is the public IP address of the local rewall that you

are trying to connect to. The address prex is the subnet prex of the local network

that you are trying to connect to. This address must be associated with a rewall

address that is provided as a gateway IP address.

Local and Virtual Network Gateways

[ 70 ]

Creating a virtual network gateway in the

portal

After a local network gateway is created, we need to create a virtual network gateway

in order to create a VPN connection between the local and Azure networks. As a local

network gateway holds information on the local network, the virtual network gateway

holds information for the Azure VNet that we are trying to connect to.

Getting ready

Before you start, open a web browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to create a new virtual network gateway, the following steps are required:

1. In the Azure portal, select Create a resource and choose Virtual network

gateway under the Networking services (or search for virtual network

gateway in the search bar).

2. Everything is done in a single blade, but for the purpose of better visibility,

I’m going to break it down into three sections. In the rst section, we need to

provide Name, Gateway type, VPN type and SKU. Optionally, we can select

Enable active-active mode:

Chapter 5

[ 71 ]

3. In the second section, we need to select the Virtual network that will be

used in the connection, and set the Public IP address options. Note that the

gateway subnet must be created prior to this, and only virtual networks with

a gateway subnet will be available for selection:

4. In the nal section, we need to select the Subscription and Location options

where the virtual network gateway will be created:

5. After validation, we can click on Create and start the deployment. Note that

creating the virtual network gateway takes longer than most other Azure

resources; deployment can take from 45 to 90 minutes.

Local and Virtual Network Gateways

[ 72 ]

How it works...

The virtual network gateway is the second part needed to establish the connection to

the Azure VNet. It’s directly connected to the virtual network and is needed to create

both Site-to-Site and Point-to-Site connections. We need to set the VPN type that

needs to match to the type of the local VPN device when a Site-to-Site connection

is created.

Creating a virtual network gateway with

PowerShell

Creating a virtual network gateway is possible with PowerShell. Again, this helps

automate processes. For example, if we start creating a virtual network gateway

using a portal and notice that our virtual network isn’t listed, it’s probably because

it’s missing a gateway subnet. So, we must abandon the process, go back and

create the gateway subnet and start creating the virtual network gateway. Using

PowerShell, we can ensure that all the requisite resources are present before starting,

and then continue with creating the virtual network gateway.

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

How to do it...

To create a new virtual network gateway, execute the following script:

$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName 'Packt-Networking-

Script' -Name 'Packt-Script'

Add-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet'

-AddressPrefix 10.11.2.0/27 -VirtualNetwork $vnet

$vnet | Set-AzureRmVirtualNetwork

$gwpip = New-AzureRmPublicIpAddress -Name VNet1GWIP -ResourceGroupName

'Packt-Networking-Script' -Location 'westeurope' -AllocationMethod

Dynamic

$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName 'Packt-Networking-

Script' -Name 'Packt-Script'

$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet'

-VirtualNetwork $vnet

Chapter 5

[ 73 ]

$gwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name gwipconfig1

-SubnetId $subnet.Id -PublicIpAddressId $gwpip.Id

New-AzureRmVirtualNetworkGateway -Name VNet1GW -ResourceGroupName 'Packt-

Networking-Script' -Location 'westeurope' -IpConfigurations $gwipconfig

-GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1

How it works...

The script performs a few different operations to make sure all requirements are

met so that we can create a virtual network gateway. The rst step is to collect

information on the virtual network that we are going to use. Next, we add the

gateway subnet to the Azure VNet, and create a public IP address that will be

used by the virtual network gateway. We collect all the information and ensure

that all the required resources are present, and then nally we create a new virtual

network gateway.

Modifying the local network gateway

settings

Network congurations may change over time, and we may need to address these

changes in Azure as well. For example, the public IP address of a local rewall may

change and we’d need to recongure the local network gateway. Or, a local network

might be recongured and the address space or subnet has changed, so we’d need to

recongure the local network gateway once again.

Getting ready

Before you start, open a web browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to modify local network gateway settings, we must do the following:

1. Locate the local network gateway in the Azure portal and go to

Conguration.

Local and Virtual Network Gateways

[ 74 ]

2. In Conguration, we can edit IP address or Address space. We can also add

additional address spaces in case we want to connect multiple local subnets

to the Azure VNet:

How it works...

The local network gateway holds the local network information needed to create a

Site-to-Site connection between the local and Azure networks. If this information

changes, we can edit it in the Conguration settings. Changes that can be made are

the IP address (that is, the public IP address of the local rewall) and the address

space we are connecting to. Additionally, we can add or remove address spaces if

we want to add or remove subnets that are able to connect to Azure VNet. If the

conguration in the local network gateway is no longer valid, we can still use it to

create a completely new connection to a new local network if needed.

[ 75 ]

Creating Hybrid Connections

Hybrid connections allow us to create secure connections with Azure VNets. These

connections can either be from on-premises or from other Azure VNets. Establishing

connections to an Azure VNet enables secure network trafc with other services

that are located in different Azure VNets, different subscriptions or outside Azure

(in different clouds or on-premises). Using secure connections removes the need for

publicly exposed endpoints that present a potential security risk. This is especially

important when we consider management, where opening public endpoints creates

a security risk and presents a major issue. For example, if we consider managing

virtual machines, it’s a common practice to use either Remote Desktop Protocol

(RDP) or PowerShell for management. Exposing these ports to public access presents

a great risk. A best practice is to disable any kind of public access to such ports and

use only access from an internal network for management. In this case, we use either

a Site-to-Site or a Point-to-Site connection to enable secure management.

In another scenario, we might need the ability to access a service or a database on

another network, either on-premises or via another Azure VNet. Again, exposing

these services might present a risk, and we use either Site-to-Site, VNet-to-VNet or

VNet peering to enable such a connection in a secure way.

We will cover the following recipes in this chapter:

• Creating a Site-to-Site connection

• Downloading the VPN device configuration from Azure

• Creating a Point-to-Site connection

• Creating a VNet-to-VNet connection

• Connecting VNets using network peering

Creating Hybrid Connections

[ 76 ]

Technical requirements

For this chapter, the following are required:

• An Azure subscription

• Windows PowerShell

Code examples can be found at https://github.com/PacktPublishing/Azure-

Networking-Cookbook/tree/master/Chapter06.

Creating a Site-to-Site connection

A Site-to-Site connection is used to create a secure connection between an on-

premises network and an Azure VNet. This connection is used to perform a number

of different tasks, such as enabling hybrid connections or secure management. In

a hybrid connection, we allow a service in one environment to connect to a service

in another environment. For example, we could have an application in Azure that

uses a database located in an on-premises environment. Secure management lets us

limit management operations to be allowed only when coming from a secure and

controlled environment, such as our local network.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To create a new Site-to-Site connection, we must follow these steps:

1. Locate the virtual network gateway (the one we created in Chapter 5, Local

and Virtual Network Gateways) and select Connections.

Chapter 6

[ 77 ]

2. In Connections, select the Add option to add a new connection:

Creating Hybrid Connections

[ 78 ]

3. In the new blade, we need to enter some information for the connection’s

Name and select Site-to-Site (IPsec) for Connection type:

Chapter 6

[ 79 ]

4. Under Local network gateway, we need to select a local network gateway

from the list (a local network gateway was created in Chapter 5, Local and

Virtual Network Gateways):

Creating Hybrid Connections

[ 80 ]

5. We need to provide a Pre-Shared Key (PSK) that will be used for the IPSec

connection. Note that options for Subscription, Resource group and Location

are locked and will be the same as they are for the virtual network gateway:

6. Finally, we select Create and the deployment will start.

Chapter 6

[ 81 ]

How it works...

Using the virtual network gateway, we set up the Azure side of the IPsec tunnel. The

local network gateway provides information on the local network, dening the local

side of the tunnel with the public IP address and local subnet information. This way,

Azure’s side of the tunnel has all the relevant information that’s needed to form a

successful connection with an on-premises network. However, this completes only

half of the work, as the opposite side of the connection must be congured as well.

This part of the work really depends on the VPN device that’s used locally, and each

device has unique conguration steps. After both sides of the tunnel are congured,

the result is a secure and encrypted VPN connection between networks.

Downloading the VPN device

conguration from Azure

After creating the Azure side of the Site-to-Site connection, we still need to congure

the local VPN device. The conguration depends upon the vendor and the device type.

You can see all the supported devices at https://docs.microsoft.com/en-gb/

azure/vpn-gateway/vpn-gateway-about-vpn-devices. In some cases, there is an

option to download conguration for a VPN device directly from the Azure portal.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To download the VPN device conguration, we must follow these steps:

1. Locate the Site-to-Site connection in the Azure portal. The Overview blade

will be opened by default.

Creating Hybrid Connections

[ 82 ]

2. Select the Download conguration option from the top of the blade:

3. A new blade will open, and you will see that all the options in the blade are

predened:

4. Select the relevant options for your given Device vendor, Device family and

Firmware version. Note that only some options are available, and not all

the supported devices have this option. After all of these options have been

selected, download the conguration le. The example le can be found in

the GitHub repository associated with this book:

Chapter 6

[ 83 ]

5. After using the conguration le for the local VPN device, both sides of the

IPsec tunnel are congured. The Status under Site-2-Site Connection will

change to Connected:

Now, let’s have a look at how it works.

Creating Hybrid Connections

[ 84 ]

How it works...

After we set up the Azure side of the IPsec tunnel, we need to congure the other

side, as well as the local VPN device. The steps and conguration are different for

each device. In some cases, we can download the conguration le directly from the

Azure portal. After the VPN device has been congured, everything is set up, and

we can use the tunnel for secure communication between the local network and an

Azure VNet.

Creating a Point-to-Site connection

Accessing resources in a secure way is important, and this must be performed

securely. It’s not always possible to perform this using a Site-to-Site connection,

especially when we have to perform something out of work hours. In this case,

we can use Point-to-Site to create a secure connection that can be established from

anywhere.

Getting ready

To create a Point-to-Site connection, we’ll need to generate a certicate that will be

used for the connection. To create a certicate, we must follow these steps:

1. Execute the following PowerShell script to generate a certicate:

$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature

-Subject "CN=P2SRootCert" -KeyExportPolicy Exportable `

-HashAlgorithm sha256 -KeyLength 2048 `

-CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign

-KeyUsage CertSign

New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert

-KeySpec Signature `

-Subject "CN=P2SChildCert" -KeyExportPolicy Exportable `

-HashAlgorithm sha256 -KeyLength 2048 `

-CertStoreLocation "Cert:\CurrentUser\My" `

-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2"

)

Chapter 6

[ 85 ]

2. Next, we need to export the certicate. Open certmgr, locate the personal

certicate, select P2SRootCert and then choose the Export... option:

3. This will start the Certicate Export Wizard. Click Next.

4. Select the No, do not export the private key option and click Next:

Creating Hybrid Connections

[ 86 ]

5. Select the Base-64 encoded X.509 format and click Next:

Chapter 6

[ 87 ]

6. Select the location where you want to save the certicate and click Next.

7. Finally, we have the option to review all the information. After clicking

Finish, the export will be complete:

Now, let’s look at the process of creating a Point-to-Site connection.

Creating Hybrid Connections

[ 88 ]

How to do it...

To create a Point-to-Site connection, we need to do the following:

1. In the Azure portal, locate the virtual network gateway and Point-to-Site

conguration.

2. We need to dene the Address pool. The Address pool here cannot overlap

with the address pool of the VNet associated with the virtual network

gateway:

3. Next, we need to select Tunnel type from the list of predened options.

In this recipe, we’ll select OpenVPN (SSL), but any option is valid:

Chapter 6

[ 89 ]

4. Locate the exported certicate (from the Getting ready section) and open it in

Notepad (or any other text editor). Select the value of the certicate and copy

this value:

Creating Hybrid Connections

[ 90 ]

5. In the Azure portal, we need to dene the root certicate. Enter the name of

the certicate and then paste the value of the certicate (from the previous

step) into the PUBLIC CERTIFICATE DATA eld:

6. After clicking Save for the Point-to-Site conguration, a new option

will become available: Download VPN client. We can download the

conguration and start using this connection:

Now, let’s have a look at how it works.

How it works...

Point-to-Site allows us to access Azure VNet in a secure way. A Site-to-Site

connection is restricted to access from our local network, but Point-to-Site allows

us to connect from anywhere. Certicate-based authentication is used, which uses

the same certicate on both the server (Azure) and the client (the VPN client) to

verify the connection and permit access. This allows us to access Azure VNet from

anywhere and at any time. This type of connection is usually used for management

and maintenance tasks, as it’s an on-demand connection. If a constant connection is

needed, you need to consider a Site-to-Site connection.

Chapter 6

[ 91 ]

Creating a VNet-to-VNet connection

Similar to the need to connect our Azure VNet to resources on a local network,

we may need to connect to resources in another Azure VNet. In such cases, we can

create a VNet-to-VNet connection that will allow us to use services and endpoints

in another VNet. This process is very similar to creating a Site-to-Site connection;

the difference is that we don’t require a local network gateway. Instead, we use two

virtual network gateways, one for each VNet.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To create a VNet-to-VNet connection, we must follow these steps:

1. In the Azure portal, locate one of the virtual network gateways (associated

with one of the VNets you are trying to connect to).

2. In the virtual network gateway blade, select Connections and select Add to

add a new connection:

Creating Hybrid Connections

[ 92 ]

3. In the new blade, enter the Name for a new connection and select VNet-to-

VNet under Connection type:

Chapter 6

[ 93 ]

4. The rst virtual network gateway will be automatically highlighted. We need

to select the second virtual network gateway:

Creating Hybrid Connections

[ 94 ]

5. We need to provide a shared key for our connection before we select Create

and start the deployment. Note that Subscription, Resource group and

Location are locked and that the values for the rst virtual network gateway

are used here:

6. The deployment of VNet-to-VNet doesn’t take long and should be done

in a few minutes. However, it takes some time to establish connections,

so the status may be Unknown for up to 15 minutes before it changes to

Connected:

Chapter 6

[ 95 ]

Now, let’s have a look at how it works.

How it works...

A VNet-to-VNet connection works very similarly to a Site-to-Site connection. The

difference is that Azure uses a local network gateway for information on the local

network. In this case, we don’t need this information; we use two virtual network

gateways to connect. Each virtual network gateway provides network information

for the VNet that it’s associated with. This results in secure, encrypted VPN

connections between two Azure VNets that can be used to establish connections

between Azure resources on both VNets.

Connecting VNets using network peering

Another option to connect two Azure VNets is to use network peering. This

approach doesn’t require the use of a virtual network gateway, so it’s more

economical to use if the only requirement is to establish a connection between Azure

VNets. Network peering uses the Microsoft backbone infrastructure to establish a

connection between two VNets, and trafc is routed through private IP addresses

only. However, this trafc is not encrypted; it’s private trafc that stays on the

Microsoft network, similar to what happens to trafc on the same Azure VNet.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

Creating Hybrid Connections

[ 96 ]

How to do it...

To create network peering, we must do the following steps:

1. In the Azure portal, locate one of the VNets that you want to connect to.

2. In the VNet blade, select the Peerings option, and select Add to add a new

connection:

Chapter 6

[ 97 ]

3. In the new blade, we must enter the name of the connection, choose a Virtual

network deployment model (Resource manager or Classic) and select

the VNet we are connecting to. This information can be provided either by

providing a resource ID, or by selecting a subscription and a VNet from the

drop-down menu. There is some additional conguration that is optional,

but provides us with better trafc control:

Creating Hybrid Connections

[ 98 ]

4. After a connection is created, we can see the information and the status for

peering. We can also change the Conguration options at any time:

Now, let’s have a look at how it works.

Chapter 6

[ 99 ]

How it works...

Network peering allows us to establish a connection between two Azure VNets in

the same Azure tenant. Peering uses a Microsoft backbone network to route private

trafc between resources on the same network, using private IP addresses only.

There is no need for virtual network gateways (which create additional cost), as a

virtual ‘remote gateway’ is created to establish a connection. The downside of this

approach is that the same VNet can’t use peering and a virtual network gateway

at the same time. If there is a need to connect a VNet to both the local network and

another VNet, we must take a different approach and use a virtual network gateway

that will allow us to create a Site-to-Site connection with a local network and a VNet-

to-VNet connection with another VNet.

[ 101 ]

DNS and Routing

Azure DNS allows us to host Domain Name System (DNS) domains in Azure.

When using Azure DNS, we use Microsoft infrastructure for the name resolution,

which results in fast and reliable DNS queries. Microsoft Azure DNS infrastructure

uses a vast number of servers to provide great reliability and availability of service.

Using Anycast networking, each DNS query is answered by the closest DNS server

available to provide a quick reply.

We will cover the following recipes in this chapter:

• Creating an Azure DNS zone

• Creating a new record set and a record in Azure DNS

• Creating a route table

• Changing the route table

• Associating the route table with a subnet

• Dissociating the route table from a subnet

• Creating a new route

• Changing a route

• Deleting a route

Technical requirements

For this chapter, the following is required:

• An Azure subscription

DNS and Routing

[ 102 ]

Creating an Azure DNS zone

To start using Azure DNS, we must rst create a DNS zone. A DNS zone holds a

DNS record for a specic domain, and it can hold records for a single domain at the

time. A DNS zone will hold DNS records for this domain and possible subdomains.

DNS name servers are set up to reply to any query on a registered domain, and point

to a destination.

Getting ready

Before you start, open your browser and go to the Azure portal via

https://portal.azure.com.

How to do it...

In order to create a new Azure DNS zone with the Azure portal, we must follow

these steps:

1. In the Azure portal, select Create a resource and choose DNS Zone under

Networking services (or search for DNS Zone in the search bar).

2. In the new blade, we must enter information for the Name, Subscription

and Resource group elds. If we select the existing resource group,

the location will be the same as the one for the resource group selected.

Name must be a Fully Qualied Domain Name (FQDN):

Chapter 7

[ 103 ]

How it works...

A DNS zone is required to start using Azure DNS. A new DNS zone is required

for each domain we want to host with Azure DNS, as a single DNS zone can hold

information for a single domain. After we create a DNS zone, we can add records,

record sets and route tables to a domain hosted with Azure DNS. Using these,

we can route trafc and dene destinations using an FQDN for Azure resources

(and other resources as well). We’ll show how to create and manage these in the

coming recipes in this chapter.

Creating a new record set and record

in Azure DNS

After creating a DNS zone, we dene what domain we’re going to hold records

for. A DNS zone is created for a ‘root’ domain dened with an FQDN. We can add

additional subdomains, and add records and record sets to hold information on

other resources on the same domain.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to add a new record to the DNS zone, we must use the following steps:

1. In the Azure portal, locate the DNS zone.

2. In the overview, select the option for adding a record set:

DNS and Routing

[ 104 ]

3. A new blade will open. Enter the name of the subdomain to which you want

to add a record:

4. We need to select the type of record we want to add. The options are A,

AAAA, CNAME, MX, NS, SRV, TXT and PTR. The most common record

type is A, so let’s select that one:

Chapter 7

[ 105 ]

5. After we select the record type, we need to select whether this is an alias and

the TTL (Time-To-Live) option. Finally, we add a record destination. This

depends on the record type, and in the case of record A, it’s going to be an IP

address:

6. Adding a single entry to our record creates a new record set and a new

record. We can add more records to the record set by adding additional IP

addresses (in this case).

DNS and Routing

[ 106 ]

How it works...

A DNS record set holds information on the subdomain in the domain hosted with

the DNS zone. In this case, the domain is toroman.cloud, and the subdomain is

test. This forms an FQDN, test.toroman.cloud, and the record points this domain

to the IP address we dened. The record set can hold multiple records for a single

subdomain, usually used for redundancy and availability.

Creating a route table

Azure routes network trafc in subnets by default. But in some cases, we want to use

custom trafc routes to dene where and how trafc ows. In this case, we use route

tables. A route table denes the next hop for our trafc and determines where the

network trafc needs to go.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to add a new record to the DNS zone, we must use the following steps:

1. In the Azure portal, select Create a resource and choose Route Table under

the Networking services (or search for route table in the search bar).

2. In the new blade, we need to provide the Name of the route table and select

the Subscription, Resource group and Location. Optionally, we can dene

whether we want to enable or disable BGP (Border Gateway Protocol) route

propagation (which is enabled by default):

Chapter 7

[ 107 ]

How it works...

Network routing in Azure VNet is done automatically, but we can use custom

routing with route tables. Route tables use rules and subnet associations to dene

trafc ow in Azure VNet. When a new route table is created, no conguration is

created – only an empty resource. After the resource is created, we need to dene

rules and subnets in order to use a route table for the trafc ow. We will show in

the coming recipes in this chapter how we create and apply rules in route tables.

Changing the route table

As mentioned in the previous recipe, creating a new route table will result in an

empty resource. Once a resource is created, we can change the settings as needed.

Before we congure the routes and subnets associated with the route table, the only

setting we can change is the BGP route propagation. We may change other settings

after creation as well.

DNS and Routing

[ 108 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to change the route table, we must do the following:

1. In the Azure portal, locate Route table.

2. Under Settings, we can change the BGP route propagation settings in the

Conguration blade. Under Settings, we can change Routes and Subnets, if

they were previously congured:

How it works...

Under the settings of the route table, we can disable or enable BGP route propagation

at any time. This option, if disabled, prevents on-premises routes from being

propagated via BGP to the network interfaces in a virtual network subnet. Under the

settings, we can create, delete or change routes and subnets. These options will be

addressed in the coming recipes in this chapter.

Chapter 7

[ 109 ]

Associating a route table with a subnet

Once a route table is created, it doesn’t do anything until it’s properly congured.

There are two things we need to address: which resources are affected, and how.

To dene which resources are affected, we must make an association between

a subnet and a route table.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to associate a subnet with a route table, we must do the following:

1. In the Azure portal, locate Route table.

2. Under Settings in the route table, select the Subnets option. In the Subnets

blade, select the Associate option to create a new association:

DNS and Routing

[ 110 ]

3. A new blade will open. There are two options available to select a Virtual

network and the Subnet we want to associate from the list:

4. First, we must select Virtual network. Selecting this option will list all the

available virtual networks. Select the one you want to associate from this list:

Chapter 7

[ 111 ]

5. After a virtual network is selected, we can proceed to select a subnet. The

subnet option will list all the subnets from the virtual network we selected

in the previous step. Choose the subnet you want to associate from this list:

6. After both options are selected, we can proceed to create an association:

DNS and Routing

[ 112 ]

7. After a subnet has been associated, it will appear in a list of subnets under

the route table:

How it works...

The route table, to be effective, must have two parts dened: the what and the how.

We dene what will be affected by the route table with a subnet association. This is

only one part of the conguration, as just associating a subnet to a route table will

do nothing. We must create rules that will apply to this association. We’ll explain

the rules in the following recipes in this chapter.

Dissociating a route table from a subnet

After we create an association and rules, those rules will apply to all resources

on the associated subnet. If we want rules to no longer apply to a specic subnet,

we can remove the association.

Chapter 7

[ 113 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to remove the association between the subnet and the route table, we must

do the following:

1. In the Azure portal, locate Route table.

2. Under Settings, select the Subnets option and select the subnet you want

to remove:

DNS and Routing

[ 114 ]

3. The subnet conguration blade will open. Select the route table option.

Note that this actually opens a subnet conguration. It’s a common

mistake to confuse this blade with the association and to choose the

Delete option. This will not only remove the association, but also

remove the subnet altogether:

Chapter 7

[ 115 ]

4. The Azure portal will show a list of the available route tables for a specic

subnet. Choose None:

5. After selecting None, click the Save button to apply the new settings.

The route table association is removed from the subnet:

DNS and Routing

[ 116 ]

How it works...

At some point, we may have created rules in a route table that apply to multiple

subnets. If we no longer want to apply one or more rules to a specic subnet, we

can remove the association. Once the association is removed, the rules will no

longer apply to the subnet. All rules will apply to all the associated subnets. If we

need to make a single rule no longer apply to a specic subnet, we must remove

the association.

Creating a new route

After we create a route table and the associated subnets, there is still a piece missing.

We dened the route table that will be affected with subnet association, but we’re

missing the part that denes how it will be affected. We dene how associated

subnets are affected with rules called routes. Routes dene trafc routes, telling

us where specic trafc needs to go. If the default route for specic trafc is the

internet, we can change this and reroute the trafc to a specic IP or subnet.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to create a new route, we must do the following:

1. In the Azure portal, locate Route table.

2. In the Route table blade, under Settings, select Routes. Select Add to add a

new route:

Chapter 7

[ 117 ]

3. In the new blade, we need to dene the Route name and the Address prex

(in CIDR format) for the destination IP address range and select Next hop

type. Options for this include Virtual network gateway, Virtual network,

Internet, Virtual appliance and None:

DNS and Routing

[ 118 ]

4. The last option, Next hop address, is active only when a virtual appliance is

used. In that case, we need to provide the virtual appliance IP address in this

eld, and all trafc will go through the virtual appliance:

How it works...

The route denes the trafc ow. All trafc from the associated subnet will follow

the route dened by these rules. If we dene that trafc will go to the internet,

all trafc will go outside the network to an IP address range dened with an IP

address prex. If we choose that trafc goes to a virtual network, it will go to a

subnet dened by the IP address prex. If that virtual network gateway is used,

all trafc will go through the virtual network gateway and reach its connection

on the other side – either another virtual network or our local network. The virtual

appliance option will send all trafc to the virtual appliance, which then, with its

own set of rules, denes where the trafc goes next.

Changing a route

Route requirements may change over time. In such cases, we can either remove the

route or edit it, depending on our needs. If the route needs to be adjusted, we can

select the option to change the route and apply the new trafc ow at any time.

Chapter 7

[ 119 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to change the existing route, we need to do the following:

1. In the Azure portal, locate Route table.

2. Under Settings, select Routes and select the route you want to change

from the list of available routes:

DNS and Routing

[ 120 ]

3. A new blade will open. We can change the Address prex (for destination IP

range) and Next hop type settings. If the next hop type is a virtual appliance,

an option for the next hop address will be available:

How it works...

The requirements for the route may change over time. We can change the route and

adjust it to suit the new requirements as needed. The most common scenarios are

that the trafc needs to reach a specic service when the service IP changes over

time. For example, we may need to route all trafc through a virtual appliance, but

the IP address of the virtual appliance changes over time. We may change the route

in the route table to reect this change and force the trafc ow through the virtual

appliance. Another example is when trafc needs to reach our local network through

a virtual network gateway – the destination IP address range may change over time,

and we need to reect these changes in the route once again.

Deleting a route

As we already mentioned, route requirements may change over time. In some cases,

the rules are no longer applicable and we must remove them. In such cases, changing

the route will not complete the task, and we need to remove the route completely.

This task may be completed by deleting the route.

Chapter 7

[ 121 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to delete the route, we must do the following:

1. In the Azure portal, locate the Route table link.

2. Under Settings, select Routes, and then select the route you want to delete:

DNS and Routing

[ 122 ]

3. A new blade will open. Select the Delete option and conrm your action:

4. After this action has been conrmed, you will return to the previous blade

and the deleted route will no longer be listed:

Chapter 7

[ 123 ]

How it works...

As our requirements change, we need to address the new requirements in our route

tables. We can either edit routes or remove them to meet these new requirements.

When multiple routes are used in a single route table, one of the routes may become

obsolete, or even block new requirements. In such cases, we may want to delete

a route to resolve any issues.

[ 125 ]

Load Balancers

Load balancers are used to support scaling and high availability for applications

and services. A load balancer is primarily composed of two components – a frontend

and a backend. Requests coming to the frontend of a load balancer are distributed

to the backend, where we place multiple instances of a service. This can be used

for performance-related reasons, where we would like to distribute trafc equally

between endpoints in the backend, or for high availability, where multiple instances

of services are used to increase the chance that at least one endpoint will be available

at all times.

We will cover the following recipes in this chapter:

• Creating an internal load balancer

• Creating a public load balancer

• Creating a backend pool

• Creating health probes

• Creating load balancer rules

• Creating inbound NAT rules

Technical requirements

For this chapter, an Azure subscription is required.

Load Balancers

[ 126 ]

Creating an internal load balancer

Microsoft Azure supports two types of load balancers – internal and external. An

internal load balancer is assigned a private IP address (from the address range of

subnets in our VNet) for a frontend IP address, and it targets the private IP addresses

of our services (usually, an Azure virtual machine (VM)) in the backend. An internal

load balancer is usually used by services that are not internet-facing and are accessed

only from within our VNet.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to create a new internal load balancer with the Azure portal, follow

these steps:

1. In the Azure portal, select Create a resource and choose Load Balancer under

the Networking services (or search for Load Balancer in the search bar).

2. In the new blade, we must select a subscription and resource group for where

the load balancer is to be created. Then, we must provide information for the

Name, Region, Type and SKU options. In this case, we select Internal for

Type to deploy an internal load balancer. Finally, we must select the Virtual

network and the Subnet that the load balancer will be associated with, along

with information of the IP address assignment, which can be Dynamic

or Static:

Chapter 8

[ 127 ]

3. After all the information is entered, we select the Review + create option to

validate the information and start the deployment of the load balancer.

How it works...

An internal load balancer is assigned a private IP address, and all requests coming

to the frontend of an internal load balancer must come to a private address, limiting

the trafc coming to the load balancer to be from within the VNet associated with the

load balancer. Trafc can come from other networks (other VNets or local networks)

if there is some kind of virtual private network (VPN) in place. The trafc coming to

the frontend of the internal load balancer will be distributed across the endpoints in

the backend of the load balancer. Internal load balancers are usually used for services

that are not placed in a demilitarised zone (DMZ) (and therefore not accessible over

the internet), but rather in middle- or back-tier services in a multi-tier application

architecture.

Load Balancers

[ 128 ]

Creating a public load balancer

The second type of load balancer in Microsoft Azure is a public load balancer.

The main difference is that a public load balancer is assigned a public IP address

in the frontend, and all requests come over the internet. The requests are then

distributed to the endpoints in the backend.

Getting ready

Before you start, open the browser and go to the Azure portal at https://portal.

azure.com.

How to do it...

In order to create a new public load balancer with the Azure portal, we must follow

these steps:

1. In the Azure portal, select Create a resource and choose Load Balancer under

the Networking services (or search for Load Balancer in the search bar).

2. In the new blade, we must select a subscription and a resource group for

where the load balancer is to be created. Then, we must provide information

for Name, Region, Type and SKU. In this case, we select Public for Type to

deploy a public load balancer:

Chapter 8

[ 129 ]

3. Selecting Public as the load balancer type will slightly change the blade.

We no longer have the option to select VNet and subnet, as we did for the

internal load balancer. Instead, we can choose options for a Public IP address

(new or existing), Public IP address SKU, IP address assignment and

whether we want to use IPv6. Note that the Public IP address SKU depends

directly on the load balancer SKU, so the SKU selected for the load balancer

will transfer automatically to the IP address:

4. After all the information is entered, we select the Review + create option to

validate the information and start the deployment of the load balancer.

How it works...

The public load balancer is assigned a public IP address at the frontend. Therefore,

all requests coming to the public load balancer will come over the internet, targeting

the load balancer’s public IP address. Requests are then distributed to endpoints in

the backend of the load balancer. What’s interesting is that the public load balancer

does not target the public IP addresses in the backend, but private IP addresses. For

example, let’s say that we have one public load balancer with two Azure VMs in the

backend. Trafc coming to the public IP address of the load balancer will then be

distributed to VMs, but will target the VMs’ private IP addresses.

Public load balancers are used for public-facing services, most commonly for

web servers.

Load Balancers

[ 130 ]

Creating a backend pool

After the load balancer is created, either internally or publicly, we must apply further

conguration in order to start using it. During the creation process, we dene the

frontend of the load balancer and know where trafc needs to go to reach the load

balancer. But, in order to dene where that trafc needs to go after reaching the load

balancer, we must rst dene a backend pool.

Getting ready

Before you start, open the browser and go to the Azure portal at https://portal.

azure.com.

How to do it...

In order to create the backend pool, we must do the following:

1. In the Azure portal, locate the previously created load balancer

(either internal or public).

2. In the Load balancer blade, under Settings, select Backend pools. Select Add

to add the new backend pool:

Chapter 8

[ 131 ]

3. In the new blade, we must provide a name and specify what the load

balancer is associated with. Associations can be created for a single VM,

availability set or virtual machine scale set. I recommend using Availability

set. Based on this selection, you will be offered a list of available resources in

the selected category to choose from:

4. After an association is created, you will be offered further options to select a

network IP conguration. In the case of selecting a virtual machine, you will

be offered to select the network interface (NIC) (as any VM can have more

than one), or in the case of the availability set, you can select between VMs in

the selected set. In this recipe, I selected an availability set, and two VMs in

that set:

Load Balancers

[ 132 ]

5. After conguration is entered, it takes a few minutes to create an association.

After that, the associated resources will show up in the Backend pool list:

How it works...

The two main components of any load balancer are the frontend and the backend.

The frontend denes the endpoint of the load balancer, and the backend denes

where the trafc needs to go after reaching the load balancer. As the frontend

information is created along with the load balancer, we must dene the backend.

Then trafc will be evenly distributed across endpoints in the backend. The available

options for the backend pool are virtual machines, availability sets and virtual

machines scale sets.

See also

More information on virtual machines, availability sets and virtual machines scale

sets is available in my book, Hands-On Cloud Administration in Azure, published by

Packt at https://www.packtpub.com/virtualization-and-cloud/hands-cloud-

administration-azure.

Creating health probes

After the frontend and the backend of the load balancer are dened, trafc is evenly

distributed among endpoints in the backend. But what if one of the endpoints is

unavailable? In that case, some of the requests will fail until we detect the issue, or

even fail indenitely should the issue remain undetected. The load balancer would

send a request to all the dened endpoints in the backend pool and the request

would fail when directed to an unavailable server.

Chapter 8

[ 133 ]

This is why we introduce the next two components in the load balancer – health

probes and rules. These components are used to detect issues and describe what to

do when issues are detected.

Health probes constantly monitor all endpoints dened in the backend pool and

detect whether any of them become unavailable.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

To create a new health probe in the load balancer, we must do the following:

1. In the Azure portal, locate the previously created load balancer

(either internal or public).

2. In the Load balancer blade, under Settings, select Health probes. Select Add

to add a new health probe:

Load Balancers

[ 134 ]

3. In the new blade, we need to provide information about the health probe’s

Name, the Protocol we want to use and the Port, Interval and Unhealthy

threshold, as shown in the following screenshot:

Chapter 8

[ 135 ]

How it works...

After we dene the health probe, it will be used to monitor the endpoints in the

backend pool. We dene the protocol and the port as useful information that will

provide information regarding whether the service we are using is available or not.

Monitoring the state of the server will not be enough, as it could be misleading. For

example, the server could be running and available, but the IIS or SQL server that

we use might be unavailable. So, the protocol and the port will detect changes in the

service that we are interested in, and not only whether the server is running. The

interval denes how often a check is performed, and the unhealthy threshold denes

after how many consecutive fails the endpoint is declared unavailable.

Creating load balancer rules

The last piece of the puzzle when speaking of Azure load balancers is the rules.

Rules nally tie all things together and dene which health probe (there can be

more than one) will monitor which backend pool (more than one can be available).

Furthermore, rules enable port mapping from the frontend of a load balancer to the

backend pool, dening how ports relate and how incoming trafc is forwarded to

the backend.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to create a load balancer rule, we must do the following:

1. In the Azure portal, locate the previously created load balancer (either

internal or public).

Load Balancers

[ 136 ]

2. In the Load balancer blade, under Settings, select Load balancing rules.

Select Add to add the load balancing rule:

3. In the new blade, we must provide information for the Name and the

IP Version we are going to use, which Frontend IP address we are going

to use (as a load balancer can have more than one), the Protocol and the

Port mapping (trafc from the incoming port will be forwarded to the

Backend port):

Chapter 8

[ 137 ]

4. In the second part of the blade, we need to provide information for the

Backend pool, Health probe, Session persistence, Idle time out (minutes)

settings and whether we want to use a oating IP:

Load Balancers

[ 138 ]

How it works...

The load balancer rule is the nal piece that ties all the components together. We

dene which frontend IP address is used, and which backend the pool trafc will be

forwarded to. The health probe is assigned to monitor the endpoints in the backend

pool and to keep track of whether there are any unresponsive endpoints. We also

create a port mapping that will determine which protocol and port the load balancer

will listen on, and when the trafc arrives, where this trafc will be forwarded.

Creating inbound NAT rules

Inbound Network Address Translation (NAT) rules are optional settings in the

Azure load balancer. These rules essentially create another port mapping from the

frontend to the backend, forwarding trafc over a specic port on the frontend to a

specic port in the backend. The difference between inbound NAT rules and port

mapping in load balancer rules is that inbound NAT rules apply to direct forwarding

to a VM, whereas load balancer rules forward trafc to a backend pool.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to create new inbound NAT rule, we must do the following:

1. In the Azure portal, locate the previously created load balancer (either

internal or public).

2. In the Load balancer blade, under Settings, select Inbound NAT rules.

Select Add to add a new inbound NAT rule:

Chapter 8

[ 139 ]

3. In the new blade, we must provide details for the Name, Frontend IP

address, Service, Protocol and Port elds:

Load Balancers

[ 140 ]

4. In the next set of options, you need to set an association and select one VM

from that association. Note that from an associated availability set, you can

select only one VM. Finally, you can select Default or Custom port mapping:

How it works...

The inbound NAT rules create a port mapping similar to the port mapping created

with the load balancer rule. The load balancer rule creates additional settings, such

as the health probe or session persistence. Inbound NAT rules exclude these settings

and create an unconditional mapping from the frontend to the backend. Another

difference is that the inbound NAT rule forwards trafc directly to a single VM,

whereas a load balancer rule forwards trafc to the backend. With the inbound NAT

rule, forwarded trafc will always reach the single server in the backend, whereas

the load balancer will forward the trafc to the backend pool and will randomly end

in any of the servers in the backend pool.

[ 141 ]

Tra󰀩c Manager

An Azure load balancer is limited to providing high availability and scalability only

to Azure virtual machines. Also, a single load balancer is limited to VMs in a single

Azure region. If we want to provide the same thing to other Azure services that are

globally distributed, we must introduce a new component – Azure Trafc Manager.

Azure Trafc Manager is DNS-based and provides the ability to distribute trafc

over services and spread trafc across Azure regions. But Trafc Manager is not

limited to Azure services; we can add external endpoints as well.

We will cover the following recipes in this chapter:

• Creating a new Traffic Manager profile

• Adding an endpoint

• Configuring distributed traffic

• Configuring traffic based on priority

• Configuring traffic based on geographical location

• Managing endpoints

• Managing profiles

• Configuring Traffic Manager with load balancers

Technical requirements

For this chapter, an Azure subscription is required.

Trafc Manager

[ 142 ]

Creating a new Tra󰀩c Manager prole

Trafc Manager provides load balancing to services, but trafc is routed and directed

using DNS entries. The frontend is a Fully Qualied Domain Name (FQDN)

assigned during creation, and all trafc coming to Trafc Manager is distributed to

endpoints in the backend. In this recipe, we’ll create a new Trafc Manager prole.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to create a new Trafc Manager prole, we must do the following:

1. In the Azure portal, select Create a resource and choose Trafc Manager

under the Networking services (or search for Traffic Manager in the

search bar).

2. In the new blade, we must provide information for the Name, Routing

method, Subscription and Resource group elds:

Chapter 9

[ 143 ]

3. Note that under Routing method, we have multiple options to choose

from – Performance, Weighted, Priority, Geographic, MultiValue and

Subnet. For this recipe, let’s leave it at the default option (Performance),

but we will cover the rest in other recipes in this chapter:

How it works...

Trafc Manager is assigned a public endpoint that must be an FQDN. All trafc

arriving at that endpoint will be distributed to endpoints in the backend, using

the routing method dened. The default routing method is performance. The

performance method will distribute trafc based on the best possible performance

available. For example, if we have more than one backend endpoint in the same

region, trafc will be spread evenly. If the endpoints are located across different

regions, Trafc Manager will direct trafc to the endpoint closest to the incoming

trafc in terms of geographical location and minimum network latency.

Adding an endpoint

After a Trafc Manager prole is created, we have the frontend endpoint and routing

method dened. But we still need to dene where the trafc needs to go after it’s

reached Trafc Manager. We need to add endpoints to the backend and dene where

the trafc is directed. In this recipe, we’ll add a new endpoint to Trafc Manager.

Trafc Manager

[ 144 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to add endpoints to Trafc Manager, we must do the following:

1. In the Azure portal, locate the previously created Trafc Manager prole.

2. In the Trafc Manager blade, under Settings, select Endpoints. Select Add to

add a new endpoint:

Chapter 9

[ 145 ]

3. In the new blade, we need to provide information for the Type of endpoint

we are adding and the Name. Based on the type, we can select certain target

resource types and based on the target resource type selection, we can select

resources that t the target resource type selected:

Trafc Manager

[ 146 ]

4. Adding a single endpoint will only work as a redirection from one FQDN

to another. We need to repeat the process at least one more time and add at

least one more endpoint:

5. All the added endpoints will appear in the list of endpoints in the Endpoints

section in the Settings section of Trafc Manager:

Chapter 9

[ 147 ]

How it works...

Incoming requests reach Trafc Manager by hitting the frontend endpoint of Trafc

Manager. Based on rules (mainly the routing method), trafc is then forwarded to

the backend endpoints. The load balancer works by forwarding trafc to private IP

addresses. On the other hand, Trafc Manager uses public endpoints in the backend.

The supported endpoint types are Azure, external and nested. Based on an endpoint

type, we can add Azure or external endpoints. Endpoints can be either (public)

FQDNs or public IP addresses. Nested endpoints allow us to add other Trafc

Manager proles to the backend of Trafc Manager.

Conguring distributed tra󰀩c

The default routing method for Trafc Manager is performance. The performance

method will distribute trafc based on the best possible performance available.

This method only takes full effect if we have multiple instances of a service in

multiple regions. As this often isn’t the case, other methods are available, such as

distributed trafc or the weighted routing method. In this recipe, we’ll congure

Trafc Manager to work in distributed mode.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

Trafc Manager

[ 148 ]

How to do it...

In order to set the distributed trafc, we must do the following:

1. In the Azure portal, locate the previously created Trafc Manager prole.

2. Under Settings, select the Conguration option. Here, we have multiple

options that we can change, such as DNS time to live (TTL), Protocol and

failover settings:

Chapter 9

[ 149 ]

3. Change Routing method to Weighted, as shown in the following screenshot.

Furthermore, we can set up weight settings if needed:

How it works...

The weighted routing method will distribute trafc evenly across all endpoints in

the backend. We can further set weight settings to give an advantage to a certain

endpoint and say that some endpoints will receive a bigger or smaller percentage

of the trafc. This method is usually used when we have multiple instances of an

application in the same region, or for scaling out to increase performance.

Conguring tra󰀩c based on priority

Another routing method available is Priority. Priority, as its name suggests, gives

priority to some endpoints, while some endpoints are kept as backups. Backup

endpoints are only used if endpoints with priority become unavailable. In this recipe,

we’ll congure Trafc Manager to route trafc based on priority.

Trafc Manager

[ 150 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to set the Routing method to Priority, we must do the following:

1. In the Azure portal, locate the previously created Trafc Manager prole.

2. Under Settings, select the Conguration option.

3. Change Routing method to Priority, as shown in the following screenshot:

Chapter 9

[ 151 ]

How it works...

Priority sets a priority order for endpoints. All trafc will rst go to the endpoints

with the highest priority. Other endpoints (with lower priority) are backed up, and

trafc is routed to these endpoints only when higher-priority endpoints become

unavailable. The default priority order is the order of adding endpoints to Trafc

Manager, where the endpoint added rst becomes the one with the highest priority

and the endpoint added last becomes the endpoint with the least priority. Priority

can be changed under the endpoint settings.

Conguring tra󰀩c based on geographical

location

Geographical location is another routing method in Trafc Manager. This method is

based on network latency, and directs a request based on the geographical location

of the origin and the endpoint. When a request comes to Trafc Manager, based on

the origin of the request, it’s routed to the nearest endpoint in terms of region. This

way, it provides the least network latency possible. In this recipe, we’ll congure

Trafc Manager to route trafc based on geographical location.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to set the routing method to the geographical location, we must do the

following:

1. In the Azure portal, locate the previously created Trafc Manager prole.

2. Under Settings, select the Conguration option.

Trafc Manager

[ 152 ]

3. Change Routing method to Geographic, as shown in the following

screenshot:

How it works...

The geographic routing method matches the request origin with the closest endpoint

in terms of geographical location.

For example, let’s say we have multiple endpoints, each on different continents. If

a request comes from Europe, it would make no sense to route it to Asia or North

America. The geographic routing method will make sure that requests coming from

Europe will be pointed to the endpoint located in Europe.

Chapter 9

[ 153 ]

Managing endpoints

After we add endpoints to Trafc Manager, we may have to make changes over time.

This can be either to make adjustments or to completely remove endpoints. In this

recipe, we’ll edit existing Trafc Manager endpoints.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to make changes to endpoints in Trafc Manager, we must do the following:

1. In the Azure portal, locate the previously created Trafc Manager.

2. Under Settings, select Endpoints. From the list that appears, select the

endpoint you want to change:

Trafc Manager

[ 154 ]

3. In the new blade, we can either delete, disable or make adjustments to

the endpoint:

How it works...

The existing endpoint in the Trafc Manager backend can be changed. We can

delete the endpoint to completely remove it from Trafc Manager, or we can disable

it to temporarily remove it from the backend. We can also change the endpoint

completely, to point to another service or a completely different type.

Managing proles

The Trafc Manager prole is another setting that we can manage and adjust.

Although it has very limited options, where we can only disable and enable Trafc

Manager, managing the prole setting can be very useful for maintenance purposes.

In this recipe, we’ll manage our Trafc Manager prole.

Chapter 9

[ 155 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to make changes to the Trafc Manager prole, we must do the following:

1. In the Azure portal, locate the previously created Trafc Manager prole.

2. In Overview, select the Disable prole option and conrm:

3. Once the prole has been disabled, it can be enabled again with the Enable

prole option:

Trafc Manager

[ 156 ]

How it works...

Managing the Trafc Manager prole with the disable and enable options will make

the Trafc Manager frontend unavailable or available (depending on the option

selected). This can be very useful for maintenance purposes. If we must apply

changes across all endpoints, and changes need to be applied to all endpoints at the

same time, we can disable the Trafc Manager prole temporarily. Once the changes

are applied to all the endpoints, we can make Trafc Manager available again by

enabling the prole.

Conguring Tra󰀩c Manager with load

balancers

Combining Trafc Manager with load balancers is often done to provide maximum

availability. Load balancers are limited to providing high availability to a set of

resources located in the same region. This gives us an advantage if a single resource

fails, as we have multiple instances of a resource. But what if a complete region fails?

Load balancers can’t handle resources in multiple regions, but we can combine load

balancers with Trafc Manager to provide even better availability with resources

across Azure regions. In this recipe, we’ll congure Trafc Manager to work with

load balancers.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to set up Trafc Manager with a load balancer, we must do the following:

1. In the Azure portal, locate the load balancer and verify that it has the

assigned IP address. Only public IP addresses can be used:

Chapter 9

[ 157 ]

2. Go to Trafc Manager and select Add to add a new endpoint. Select Azure

endpoint as the Type, provide a name for the endpoint, and select Public IP

address as the target resource type. Under Target resource, select the public

IP address associated with the load balancer:

3. Repeat the process and add another load balancer (from another region) as

the Trafc Manager endpoint.

Trafc Manager

[ 158 ]

How it works...

Load balancers provide better high availability, keeping a service active even if

one of the services in the backend pool fails. If a region fails, load balancers can’t

provide help because they are limited to a single region. We must provide another

set of resources in another region to truly increase availability, but these sets

will be completely independent and will not provide failover unless we include

Trafc Manager. Trafc Manager will become the frontend, and we will add load

balancers as the backend endpoints of Trafc Manager. All requests will come to

Trafc Manager rst, and will then be routed to the appropriate load balancer in the

backend. Trafc Manager will monitor the health of the load balancers, and if one of

them becomes unavailable, the trafc will be rerouted to an active load balancer.

[ 159 ]

Azure Application Gateway

Azure Application Gateway is essentially a load balancer for web trafc, but it

also provides you with better trafc control. Classic load balancers operate on the

transport layer, and they allow you to route trafc based on protocol (TCP or UDP)

and IP address, mapping IP addresses and protocols in the frontend to IP addresses

and protocols in the backend. Azure Application Gateway expands on that and

allows us to use URLs and paths to determine where trafc should go. For example,

we can have multiple servers that are optimised for different things. If one of our

servers is optimised for video, then all video requests should be routed to that

specic server based on the incoming URL request.

We will cover the following recipes in this chapter:

• Creating a new application gateway

• Configuring the backend pool

• Creating HTTP settings

• Creating a listener

• Creating a rule

• Creating a probe

• Configuring a Web Application Firewall (WAF)

• Customising WAF rules

Azure Application Gateway

[ 160 ]

Technical requirements

For this chapter, an Azure subscription is required.

Creating a new application gateway

Azure Application Gateway can be used as a simple load balancer to perform trafc

distribution from the frontend to the backend based on protocols and ports. But it

can also expand on that, and perform additional routing based on URLs and paths.

This allows us to have resource pools based on roles and also allows us to optimise

specic performance. Using these options and performing routing based on context

will increase application performance, along with providing high availability. Of

course, in this case, we need to have multiple resources for each performance type in

each backend pool (each performance type requests a separate backend pool).

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to create a new application gateway, we must do the following:

1. In the Azure portal, select Create a resource and choose Application

Gateway under the Networking services (or search for application

gateway in the search bar).

Chapter 10

[ 161 ]

2. In the new blade, we must provide information for Name, Tier, Instance

count, SKU size, Subscription, Resource group and Location. Note that

the virtual network and public IP address (associated with the application

gateway) must be in the same region as the application gateway:

Azure Application Gateway

[ 162 ]

3. Under Settings, we must select the Virtual network that will be associated

with our application gateway. You will be limited to virtual networks that

are located in the region that is selected for the application gateway:

4. Based on your virtual network selection, we must also provide a Subnet

from the virtual network associated with the application gateway. Further to

this, we must provide information for the frontend IP address (select either

the public or private address type). If IP address type is set to Public, a new

set of options will appear where we need to dene whether we want a new

or existing public IP address, along with dening an SKU and DNS name

label for the public IP address, as shown in the following screenshot:

Chapter 10

[ 163 ]

Azure Application Gateway

[ 164 ]

5. Finally, we must dene the default listener. For the listener, we must select

whether we are going to use HTTP or HTTPS, assign the Port and enable

or disable HTTP2 (Disabled is the default option). Note that the rewall

settings are available only when the application gateway SKU is set to WAF:

6. Finally, the summary is shown, where we can check the settings one more

time before deployment is started:

Chapter 10

[ 165 ]

How it works...

Azure Application Gateway is very similar to load balancers, with some additional

options. It will route trafc coming to the frontend of the application gateway to

a dened backend, based on rules that we dene. In addition to routing based on

protocol and port, the application gateway also allows dened routing based on URL

and request type. Using these additional rules, we can route incoming requests to

endpoints that are optimised for certain roles. For example, we can have multiple

backend pools with different settings that are optimised to perform only specic

tasks. Based on incoming requests, the application gateway will route the request

to the appropriate backend pool. This approach, along with high availability, will

provide better performance by routing each request to a backend pool that will

process the request in a more optimised way.

Conguring the backend pool

After the application gateway is created, we must dene backend pools. Trafc

coming to the frontend of the application gateway will be forwarded to the backend

pools. Backend pools in application gateways are the same as backend pools in load

balancers, and are dened as possible destinations where trafc will be routed based

on other settings that will be added in future recipes in this chapter.

Azure Application Gateway

[ 166 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to add backend pools to our application gateway, we must do the following:

1. In the Azure portal, locate the previously created application gateway.

2. In the Application gateway blade, under Settings, select Backend pools.

Select Add to add a new backend pool:

3. In the new blade, we must provide the name of the backend pool and the

type of target. Available types are virtual machines, virtual machine scale

sets, app services and IP addresses/FQDNs. Based on the type you choose,

you can add appropriate targets:

Chapter 10

[ 167 ]

How it works...

With backend pools, we dene targets to which trafc will be forwarded. As the

application gateway allows us to dene routing by request type, it’s best to have

targets based on performance and types grouped in the same way. For example, if

we have multiple web servers, these should be placed in the same backend pool.

Servers used for data processing should be placed in a separate pool, and servers

used for video in another separate pool. This way, we can separate pools based on

performance types, and route trafc based on operations that need to be completed.

This will increase the performance of our application, as each request will be

processed by the resource that’s best suited for a specic task. To achieve high

availability, we should add more servers to each backend pool.

Azure Application Gateway

[ 168 ]

Creating HTTP settings

HTTP settings in application gateways are used for validation and various

trafc settings. Their main purpose is to ensure that the request is directed to the

appropriate backend pool. Some other HTTP settings are also included, such as

afnity and connection draining. Override settings are also part of HTTP settings

that will allow you to force-redirect if an incomplete or wrong request is sent.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to add HTTP settings to our application gateway, we must do the following:

1. In the Azure portal, locate the previously created application gateway.

2. In the Application gateway blade, under Settings, select HTTP settings.

Select Add to add a new HTTP setting:

Chapter 10

[ 169 ]

3. In the new blade, rst, we need to provide a Name. The next options allow us

to disable or enable options such as Cookie based afnity and Connection

draining. Further to this, we select our Protocol, Port and the Request

time out (seconds) period. Optional settings include using it for the app

service or custom probes, or to pick a host name from the backend address

pool. The override settings on offer are Override backend path and Override

host name:

Azure Application Gateway

[ 170 ]

How it works...

As previously mentioned, the main purpose of HTTP settings is to ensure that

requests are directed to the correct backend pool. But various other options are

available. Cookie-based afnity allows us to route requests from the same source to

the same target server in the backend pool. Connection draining will control how

the server can be removed from the backend pool. If this is enabled, the server can

be removed only when all active connections have stopped. Override settings allow

us to override the path of the URL to a different path or a completely new domain,

before forwarding the request to the backend pool.

Creating a listener

Listeners in the application gateway listen for any incoming requests. After a

new request is detected, it’s forwarded to the backend pool based on the rules and

settings we have dened.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to add a listener to the application gateway, we must do the following:

1. In the Azure portal, locate the previously created application gateway.

2. In the Application gateway blade, under Settings, select Listeners, then

select Basic to add a new listener:

Chapter 10

[ 171 ]

3. In the new blade, we need to provide a name for the listener, select the

Frontend IP conguration and provide a Port and Protocol that will be

monitored:

Azure Application Gateway

[ 172 ]

How it works...

A listener monitors for new requests coming to the application gateway. Each

listener monitors only one frontend IP address and only one port. If we have

multiple frontend IPs and trafc coming in over multiple protocols and ports, we

must create a listener for each IP address and each port that trafc may be coming to.

Creating a rule

Rules in application gateways are used to determine how trafc ows. Based on

different settings, we can determine where a specic request is forwarded to and

how this is done.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to add a rule to the application gateway, we must do the following:

1. In the Azure portal, locate the previously created application gateway.

2. In the Application gateway blade, under Settings, select Rules. Select Basic

to add a new rule:

Chapter 10

[ 173 ]

3. In the new blade, we must provide a name for the new rule and select

the Listener, Backend pool and HTTP setting, as shown in the following

screenshot:

How it works...

Using rules, we can tie some previously created settings together. We dene a

listener that species which request on what IP address are we expecting over

which port. Then, these requests are forwarded to the backend pool; forwarding is

performed based on the HTTP settings. Optionally, we can also add redirection into

the rules.

Creating a probe

Probes in Azure Application Gateway are used to monitor the health of the

backend endpoints. Each endpoint is monitored, and if found to be unhealthy, it is

temporarily taken out of the pool. Once the status changes, it’s added back to the

pool. This prevents requests from being sent to unhealthy endpoints that couldn’t

resolve the request.

Azure Application Gateway

[ 174 ]

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to add a probe to our application gateway, we must do the following:

1. In the Azure portal, locate the previously created application gateway.

2. In the Application gateway blade, under Settings, select Health probes.

Select Add to add the new probe:

3. In the new blade, we must provide the Name of the probe, along with the

Protocol, Host and Path. We also need to set the Interval, Time out and

Unhealthy threshold:

Chapter 10

[ 175 ]

How it works...

Protocol, Host and Path dene what probe is being monitored. Interval denes how

often checks are performed. Time out denes how much time must pass before the

check is declared to be failed. Finally, Unhealthy threshold is used to set how many

failed checks must occur before the endpoint is declared unavailable.

Azure Application Gateway

[ 176 ]

Conguring a Web Application Firewall (WAF)

WAF is an additional setting for the application gateway. It’s used to increase

the security of applications behind the application gateway, and also provides

centralised protection.

Getting ready

To enable WAF, we must set the application gateway to the WAF tier. To do so, we

must do the following:

1. In the Application gateway blade, go to Conguration under Settings, as

shown in the following screenshot:

2. Change the Tier selection from Standard to WAF. Click the Save button:

Chapter 10

[ 177 ]

How to do it...

After the application gateway is set to WAF, we can enable and set the rewall rules.

To do so, we must do the following:

1. In the Application gateway blade, go to Web application rewall, under

Settings:

Azure Application Gateway

[ 178 ]

2. After we set Firewall status to Enabled, a new set of options will appear:

3. We must select a Firewall mode, the exclusion list and specify the Global

parameters as follows:

Chapter 10

[ 179 ]

How it works...

The WAF feature helps increase security by checking all incoming trafc. As this

can slow down performance, we can exclude some items. Excluded items will not be

checked. WAF can work in two modes: detection and prevention. Detection will only

detect if a malicious request is sent, while prevention will stop any such request.

Customising WAF rules

WAF comes with a predetermined set of rules. These rules are enforced to increase

application security and prevent malicious requests. We can change these rules to

address specic issues or requirements as needed.

Getting ready

Before you start, open the browser and go to the Azure portal at

https://portal.azure.com.

How to do it...

In order to change the WAF rules, we must do the following:

1. Select Web application rewall under Settings in the Application gateway

blade.

2. Select Rules in the WAF settings. Set Advanced rule conguration to

Enabled, as shown in the following screenshot:

Azure Application Gateway

[ 180 ]

3. The rules will appear in the form of a list. We can check or uncheck boxes to

enable or disable rules:

How it works...

WAF comes with all rules activated by default. This can slow down performance, so

we can disable some of the rules if needed. Also, there are two rule sets available –

OWASP 2.2.9 and OWASP 3.0. The default rule set is OWASP 3.0, but we can switch

between rule sets as per our requirements.

[ 181 ]

Azure Firewall

Most Azure networking components used for security are there to stop unwanted

incoming trafc. Whether we use network security groups, application security

groups or a web application rewall, they all have one single purpose – to stop

unwanted trafc reaching our services. Azure Firewall has similar functionality,

including one extension that we can use to stop outbound trafc from leaving the

virtual network.

We will cover the following recipes in this chapter:

• Creating a new Azure Firewall

• Configuring a new allow rule

• Configuring a new deny rule

• Configuring a route table

• Enabling diagnostic logs for Azure Firewall

Technical requirements

For this chapter, the following is required:

• An Azure subscription

• Azure PowerShell

Code examples can be found at https://github.com/PacktPublishing/Azure-

Networking-Cookbook/tree/master/Chapter11.

Azure Firewall

[ 182 ]

Creating a new Azure Firewall

Azure Firewall allows us total control over our trafc. Besides controlling inbound

trafc, with Azure Firewall, we can control outbound trafc as well.

Getting ready

Before we can create an Azure Firewall instance, we must prepare the subnet.

In order to create a new subnet for Azure Firewall, we must do the following:

1. Locate the virtual network that will be associated with our Azure Firewall.

2. Select the Subnets option under Settings and select the option to add a new

subnet, as shown in the following screenshot:

3. In the new blade, we must provide the Name and Address range. It’s very

important that the subnet is named AzureFirewallSubnet:

Chapter 11

[ 183 ]

How to do it...

In order to create a new Azure Firewall instance using the Azure portal, take the

following steps:

1. In the Azure portal, select Create a resource and choose Azure Firewall

under Networking services (or search for Azure Firewall in the search bar).

Azure Firewall

[ 184 ]

2. In the new blade, rst, we must provide values for the Subscription and

Resource group drop-down menus. We need to ll in the Name and Region

elds for Azure Firewall, as shown in the following screenshot:

3. Next, we proceed to virtual network selection. Only virtual networks in the

region where the Azure Firewall instance will be created are available. Also,

the selected virtual network must contain the AzureFirewallSubnet subnet

we created earlier. Finally, we dene a Public IP address, as shown in the

following screenshot:

Chapter 11

[ 185 ]

How it works...

Azure Firewall uses a set of rules to control outbound trafc. We can either block

everything by default and allow only whitelisted trafc, or we can allow everything

and block only blacklisted trafc.

Conguring a new allow rule

If we want to allow specic trafc, we must create an allow rule. Rules are applied

based on priority level, so a rule will be applied only when there is no other rule

with higher priority.

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

How to do it...

In order to create a new allow rule in Azure Firewall, execute the following

command:

$RG="Packt-Networking-Portal"

$Location="West Europe"

$Azfw = Get-AzureRmFirewall -ResourceGroupName $RG

$Rule = New-AzureRmFirewallApplicationRule -Name Rule1 -Protocol

"http:80","https:443" -TargetFqdn "*packt.com"

$RuleCollection = New-AzureRmFirewallApplicationRuleCollection -Name

RuleCollection1 -Priority 100 -Rule $Rule -ActionType "Allow"

$Azfw.ApplicationRuleCollections = $RuleCollection

Set-AzureRmFirewall -AzureFirewall $Azfw

How it works...

An allow rule in Azure Firewall will whitelist specic trafc. If there is a rule that

would also block this trafc, the higher-priority rule will be applied.

Conguring a new deny rule

If we want to deny specic trafc, we must create a deny rule. Rules are applied by

priority, so this rule will be applied only if there is not a higher-priority rule in effect.

Azure Firewall

[ 186 ]

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

How to do it...

In order to create a new deny rule in Azure Firewall, execute the following

command:

$RG="Packt-Networking-Portal"

$Location="West Europe"

$Azfw = Get-AzureRmFirewall -ResourceGroupName $RG

$Rule = New-AzureRmFirewallApplicationRule -Name Rule1 -Protocol

"http:80","https:443" -TargetFqdn "*google.com"

$RuleCollection = New-AzureRmFirewallApplicationRuleCollection -Name

RuleCollection1 -Priority 100 -Rule $Rule -ActionType "Deny"

$Azfw.ApplicationRuleCollections = $RuleCollection

Set-AzureRmFirewall -AzureFirewall $Azfw

How it works...

The deny rule is the most commonly used option with Azure Firewall. An approach

where you block everything and allow only whitelisted trafc isn’t very practical, as

we may end up adding too many allow rules. Therefore, the most common approach

is to use deny rules to block certain trafc that we want to prevent.

Conguring a route table

Route tables are commonly used with Azure Firewall when there is cross-

connectivity. Cross-connectivity can either be with other Azure virtual networks,

or with on-premises networks. In such cases, Azure Firewall uses route tables to

forward trafc based on the rules specied in the route tables.

Getting ready

Open the PowerShell console and make sure you are connected to your Azure

subscription.

Chapter 11

[ 187 ]

How to do it...

In order to create a new route table in Azure Firewall, execute the following

command:

$RG="Packt-Networking-Portal"

$Location="West Europe"

$Azfw = Get-AzureRmFirewall -ResourceGroupName $RG

$config = $Azfw.IpConfigurations[0].PrivateIPAddress

$Route = New-AzureRmRouteConfig -Name 'Route1' -AddressPrefix

0.0.0.0/0 -NextHopType VirtualAppliance -NextHopIpAddress $config

$RouteTable = New-AzureRmRouteTable -Name 'RouteTable1'

-ResourceGroupName $RG -location $Location -Route $Route

How it works...

Using route tables associated with Azure Firewall, we can dene how trafc between

networks is handled and how we route trafc from one network to another. In

a multi-network environment, especially in a hybrid network where we connect

an Azure virtual network with a local on-premises network, this option is very

important. This allows us to determine what kind of trafc can ow where and how.

Enabling diagnostic logs for Azure

Firewall

Diagnostics are a very important part of any IT system, and networking is no

exception. The diagnostics settings in Azure Firewall allow us to collect various

information that can be used for troubleshooting or auditing.

Getting ready

Before you start, open your browser and go to the Azure portal at

https://portal.azure.com.

Azure Firewall

[ 188 ]

How to do it...

To enable diagnostics in Azure Firewall, we must follow these steps:

1. In the Firewall blade, locate Diagnostics settings under Monitoring.

2. Select the Turn on diagnostics option, as shown in the following screenshot:

3. In the new blade, ll in the Name eld and specify where the logs will be

stored. Choose the Storage account where the logs will be stored, and specify

the retention period and which logs will be stored, as shown in the following

screenshot:

Chapter 11

[ 189 ]

How it works...

Diagnostics has two purposes – auditing and troubleshooting. Based on trafc

and settings, these logs can grow over time, so it’s important to consider the main

purpose for enabling diagnostics in the rst place. If diagnostics are enabled for

auditing, you will probably want to choose a maximum of 365 days of retention. If

the main purpose is troubleshooting, the retention period can be kept at seven days

or an even shorter time.

[ 191 ]

Other Books You May Enjoy

If you enjoyed this book, you may be interested in these other books by Packt:

Learn Microsoft Azure

Mohamed Wali

ISBN: 978-1-78961-758-0

• Understand the cloud services offered by Azure

• Design storage and networks in Azure for your Azure VM

• Work with web apps and Azure SQL databases

• Build your identity management solutions on Azure using Azure AD

• Monitor, protect and automate your Azure services using Operation

Management Suite (OMS)

• Implement OMS for Azure services

Other Books You May Enjoy

[ 192 ]

Azure Serverless Computing Cookbook – Second Edition

Praveen Kumar Sreeram

ISBN: 978-1-78961-526-5

• Integrate Azure Functions with other Azure services

• Understand cloud application development using Azure Functions

• Employ durable functions for developing reliable and durable serverless

applications

• Use SendGrid and Twilio services

• Explore code reusability and refactoring in Azure Functions

• Configure serverless applications in a production environment

Other Books You May Enjoy

[ 193 ]

Leave a review – let other readers know

what you think

Please share your thoughts on this book with others by leaving a review on the site

that you bought it from. If you purchased the book from Amazon, please leave us

an honest review on this book’s Amazon page. This is vital so that other potential

readers can see and use your unbiased opinion to make purchasing decisions, we

can understand what our customers think about our products and our authors can

see your feedback on the title that they have worked with Packt to create. It will only

take a few minutes of your time, but is valuable to other potential customers, our

authors and Packt. Thank you!

[ 195 ]

Index

allow rule

conguring 185

application gateway

about 160, 162

backend pools, adding 166, 167

creating 160, 162, 164

HTTP settings, adding 168, 169, 170

listener, adding 170, 171, 172

probe, adding 174, 175

rule, adding 172, 173

working 165

Azure

VPN device conguration, downloading

from 81, 82, 84

Azure DNS

record, creating 103, 104, 105

record set, creating 103, 104, 105

Azure DNS zone

creating 102, 103

Azure Firewall

creating 182, 183, 184, 185

diagnostic logs, enabling for 187, 188, 189

Azure Virtual Network (VNet) 67

Azure VMs

creating 17

backend pool

conguring 165, 166, 167

creating 130, 131, 132

demilitarised zone (DMZ) 127

deny rule

conguring 185, 186

diagnostic logs

enabling, for Azure Firewall 187, 188, 189

distributed trafc

conguring 147, 149

Domain Name System (DNS) 101

endpoint

adding, to Trafc Manager 143, 144, 146,

147

managing 153, 154

external load balancer 126

Fully Qualied Domain Name (FQDN) 102,

142

health probes

about 132

creating 133, 134

working 135

HTTP settings

about 168

creating 168, 169, 170

[ 196 ]

internal load balancer

about 126

creating 126, 127

listener

about 170

creating 170, 171, 172

load balancer

health probes 133

rules 133

load balancer rules

about 135

creating 135, 136, 137, 138

load balancers

Trafc Manager, conguring with 156, 157,

158

local network gateway

creating, in portal 68, 69

creating, with PowerShell 69

local network gateway settings

modifying 73, 74

Network Address Translation (NAT) rules

about 138

creating 138, 139, 140

working 140

network interface

attaching, to VM 25

creating 23, 25

detaching, from VM 26, 27

network interface (NIC) 53, 131

network peering

used, for connecting VNets 95, 96, 97, 98, 99

network settings, VMs

viewing 22, 23

options, for backend pool

availability sets 132

machines scale sets 132

virtual machines 132

OWASP 2.2.9 180

OWASP 3.0 180

Point-to-Site connection

about 84

creating 84, 85, 86, 87, 88, 89, 90

portal

local network gateway, creating in 68, 69

virtual network gateway, creating in 70,

71, 72

PowerShell

local network gateway, creating 69

virtual network gateway, creating 72

Pre-Shared Key (PSK) 80

probe

about 173

creating 174, 175

Web Application Firewall (WAF),

conguring 176

public load balancer

about 128

creating 128, 129

record

creating, in Azure DNS 103, 104, 105

record set

creating, in Azure DNS 103, 104, 105

Remote Desktop Protocol (RDP) 75

route

creating 116, 117, 118

deleting 120, 121, 122

modifying 118, 119, 120

route table

associating, with subnet 111

conguring 186, 187

creating 106, 107

dissociating, from subnet 115

modifying 107, 108

rule

about 172

creating 172, 173

[ 197 ]

Site-to-Site connection

about 76

creating 76, 78, 79, 80, 81

subnet

route table, associating with 111

route table, dissociating from 115

trafc

conguring, based on geographical location

151, 152

conguring, based on priority 149, 151

Trafc Manager

conguring, with load balancers 156, 157,

158

endpoint, adding to 143, 144, 146, 147

Trafc Manager prole

creating 142, 143

managing 154, 155, 156

Virtual Machines (VMs)

network interface, attaching to 25

network interface, detaching 26

network settings, viewing 22, 23

virtual machine (VM) 126

virtual network gateway

creating, in portal 70, 71, 72

creating, with PowerShell 72

virtual private network (VPN) 67, 127

VNets

connecting, network peering used 95, 96,

97, 98, 99

VNet-to-VNet connection

about 91

creating 91, 92, 93, 94, 95

VPN device conguration

downloading, from Azure 81, 82, 83

reference link 81

WAF rules

customising 179, 180

Web Application Firewall (WAF)

conguring 176, 177, 178, 179

rules, customising 179