Creating Hybrid Connections
Creating Hybrid Connections
Creating Hybrid Connections
Creating hybrid
connections
Hybrid connections allow us to create secure connections with Azure virtual networks
(VNets). These connections can either be from on-premises or from other Azure VNets.
Establishing connections to Azure VNets enables the exchange of secure network traffic
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.
124 | Creating hybrid connections
Technical requirements
For this chapter, the following are required:
• An Azure subscription
• Windows PowerShell
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.
2. In Connections, select the Add option to add a new connection:
3. In the new pane, we need to enter the connection name and select Site-to-site
(IPsec) for Connection type:
4. Under Local network gateway, we need to select a local network gateway from
the list (we created a local network gateway in Chapter 5, Local and virtual network
gateways):
5. We need to provide a shared key in the Shared key (PSK) field that will be used for
the IPSec connection. We also need to define the IKE protocol that will be used
for security association. We can choose between IKEv1 and IKEv2. Note that the
options for Subscription, Resource group, and Location are locked and will be the
same as they are for the virtual network gateway:
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, defining 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 configured as well. This part
of the work really depends on the VPN device that's used locally, and each device has
unique configuration steps. After both sides of the tunnel are configured, the result is a
secure and encrypted VPN connection between networks.
Let's take a look at how to configure our local VPN device.
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 configuration, we must follow these steps:
1. Locate the Site-2-Site connection in the Azure portal. The Overview pane will be
opened by default.
2. Select the Download configuration option from the top of the pane:
3. A new pane will open, and you will see that all the options in the pane are
predefined:
4. Select the relevant options for the Device vendor, Device family, and Firmware
version fields. Note that only some options are available, and not all the supported
devices have these options. After all of these options have been selected, download
the configuration file. The sample file (Site-2-Site.txt in the Chapter 8 folder) can
be found in the GitHub repository associated with this book:
5. After using the configuration file for the local VPN device, both sides of the IPsec
tunnel are configured. The Status value under the Site-2-Site connection will
change to Connected:
How it works...
After we set up the Azure side of the IPsec tunnel, we need to configure the other
side, as well as the local VPN device. The steps and configuration are different for each
device. In some cases, we can download the configuration file directly from the Azure
portal. After the VPN device has been configured, everything is set up, and we can use
the tunnel for secure communication between the local network and the VNet.
Getting ready
To create a Point-to-Site connection, we'll need to generate a certificate that will be
used for the connection. To create a certificate, we must follow these steps:
1. Execute the following PowerShell script to generate a certificate:
$cert = New-SelfSignedCertificate -Type Custom '
-KeySpec Signature '
-Subject "CN=P2SRootCert" '
-KeyExportPolicy Exportable '
-HashAlgorithm sha256 -KeyLength 2048 '
-CertStoreLocation "Cert:\CurrentUser\My" '
Creating a Point-to-Site connection | 131
4. Select the No, do not export the private key option and click Next:
5. Select the Base-64 encoded X.509 (.CER) format and click Next:
6. Select the location where you want to save the certificate and click Next.
7. Finally, we have the option to review all the information. After clicking Finish, the
export will be complete:
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 User VPN
configuration. Select Configure now:
2. We need to define 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 a Tunnel type option from the list of predefined options.
In this recipe, we'll select OpenVPN (SSL), but any option is valid:
4. Locate the exported certificate (from the Getting ready section) and open it in
Notepad (or any other text editor). Select the value of the certificate and copy this
value as follows:
5. In the Azure portal, we need to define the root certificate. Enter the name of the
certificate and then paste the value of the certificate (from the previous step) into
the Public certificate data field:
6. After clicking Save for the Point-to-Site configuration, a new option will become
available: Download VPN client. We can download the configuration and start
using this connection:
How it works...
Point-to-Site allows us to access Azure VNets in a secure way. Access to a Site‑to‑Site
connection is restricted to our local network, but Point-to-Site allows us to connect
from anywhere. Certificate-based authentication is used, which uses the same
certificate on both the server (Azure) and the client (the VPN client) to verify the
connection and permit access. This allows us to access Azure VNets 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.
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 pane, select Connections and select Add to add a
new connection:
Creating a VNet-to-VNet connection | 137
3. In the new pane, enter a Name value for the new connection and select VNet-to-
VNet under Connection type:
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 first 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 you may see the
status Unknown for up to 15 minutes before it changes to Connected:
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.
Now, let's learn about using network peering to connect VNets.
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 network peering, we must take the following steps:
1. In the Azure portal, locate one of the VNets that you want to connect to.
2. In the Virtual network pane, select the Peerings option, and select Add to add a
new connection:
3. In the new pane, we must enter the name of the connection, select a Virtual
network deployment model option (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 Subscription and Virtual network options from the
drop-down menu. There are some additional configurations that are optional but
provide us with better traffic control:
Connecting VNets using network peering | 141
4. After a connection is created, we can see the information and the status for
peering. We can also change the Configuration options at any time:
Figure 8.26: Reviewing the peering information and status for a new connection
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 traffic
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 VNet to both the local network and another VNet, we must take
a different approach and use a virtual network gateway, which will allow us to create
a Site-to-Site connection with a local network and a VNet-to-VNet connection with
another VNet.
When it comes to network access settings, we have multiple options to control network
traffic flow. For example, we can say that traffic is allowed from VNet A to VNet B, but
denied from VNet B to VNet A. Of course, we can set it the other way around or make it
bidirectional.
We can also control transit traffic when an additional network is in the mix. If VNet A is
connected to VNet B, and additionally VNet A is connected to VNet C, we can control
whether traffic is allowed between VNet B and VNet C as transit traffic through VNet A.
However, this only works if transit is not made via peering. If all networks are Azure
VNets, and VNet A connected to VNet B via peering, and VNet B connected to VNet
C via peering, the connection between VNet A and VNet C would not be possible via
transit between VNets. This is because peering is a non-transitive relationship between
two VNets. If VNet B is connected to VNet C via VNet-to-VNet (or to an on-premises
network via Site-to-Site), transit would be possible between VNet A and VNet C over
VNet B.