Introduction to Azure VPN Gateway

-

 


    A virtual private network (VPN) provides a secure encrypted connection across another network. VPNs typically are deployed to connect two or more trusted private networks to one another over an untrusted network such as the internet. Traffic is encrypted while traveling over the untrusted network to prevent a third party from eavesdropping on the network communication.

    You are responsible for networking at Adatum, a home maintenance, security, and automation company. Adatum has several multi-tier applications that run on Windows and Linux virtual machines. These virtual machines are in the process of being migrated from an on-premises datacenter to the Microsoft Azure cloud. These applications store sensitive customer information and the virtual machines that host them should never be exposed directly to the internet.

    Adatum has a large number of remote workers who use laptop computers to interact with these applications. Because the VMs that host the applications are connected to the Adatum on-premises internal network, these remote workers use a third-party VPN to connect to that internal network to access these applications. Users at Adatum's main office make direct connections to the applications. The applications don't require significant amounts of bandwidth to operate successfully and are resilient to fluctuations in latency.

    You want to ensure that remote workers are able to securely connect to these applications when the migration to Azure is complete. You also want to ensure that workers connected to Adatum's internal network are able to connect to the applications without concern about their network traffic being intercepted. In future, Adatum is also likely to deploy more subnets on its virtual networks and to also deploy more IaaS workloads on virtual networks around the world. The possibility of an expansion of virtual networks and subnets should be incorporated into any solution that you decide upon.

What is Azure VPN Gateway?

    An Azure VPN gateway is a specific type of virtual network gateway that is used to send and receive encrypted traffic between an Azure virtual network and an on-premises location over the public Internet. Azure VPN gateways can also be used to connect separate Azure virtual networks using an encrypted tunnel across the Microsoft network backbone.



Azure VPN Gateway supports both point-to-site and site-to-site connections:
  • Point-to-site VPN connection. A point-to-site VPN connection can be used to connect a single computer to an Azure virtual network. A P2S connection is established by starting it from the client computer. This type of VPN connection is commonly used by remote workers with portable computers.
  • Site-to-site VPN connection. A site-to-site VPN connection allows you to connect one network to another network with traffic between the two networks passing across an encrypted VPN tunnel. This type of VPN connection is commonly used to connect on-premises sites to Azure or Azure virtual networks to each other.

Depending on the SKU chosen, Azure VPN gateways support:
  • Between 10 and 30 site-to-site connections.
  • 100 Mbps to 1.25 Gbps aggregate throughput.
  • Border Gateway Protocol (BGP) support.

How Azure VPN Gateway works

    You can deploy only one VPN gateway in each Azure virtual network. Even though you are limited to a single VPN gateway, you can configure this gateway to connect to multiple locations, including other Azure virtual networks or on-premises datacenters.

VPN gateway types

    When you configure a virtual network gateway, you select a setting that specifies the gateway type. The gateway type determines how the virtual network gateway will be used and the actions that the gateway takes. The gateway type Vpn specifies that the type of virtual network gateway created is a VPN gateway. This distinguishes it from an ExpressRoute gateway, which uses a different gateway type. An Azure virtual network can have two virtual network gateways: one VPN gateway and one ExpressRoute gateway.

There are two types of Azure VPN gateways:
  • Policy-based VPN gateway
  • Route-based VPN gateway

Policy-based VPN gateways

    Policy-based VPN gateways require that you specify a fixed set of IP address of packets that should be encrypted through each tunnel. This type of device evaluates every data packet against those fixed sets of IP addresses and then chooses the tunnel through which it will send that traffic.

Key features of policy-based VPN gateways in Azure include:

  • Support for IKEv1 only.
  • Use of static routing.
    The source and destination of the tunneled networks are declared in the VPN policy and don't need to be declared in routing tables. Use policy-based VPNs only in specific scenarios that require them, such as for compatibility with legacy on-premises VPN devices.

Route-based VPN gateways

    With route-based Azure VPN gateways, an IPsec tunnel functions as a network interface or virtual tunnel interface (VTI). IP routing (static routes or dynamic routing protocols) determines which tunnel interfaces will transmit each packet. Route-based VPNs are the preferred connection method for on-premises devices, since they are more resilient to topology changes such as the creation of new subnets. A route-based VPN is far more suitable for Adatum because it will allow connections to be made to Azure IaaS resources on virtual networks if new subnets are added without having to reconfigure the Azure VPN gateway.

Use a route-based VPN gateway if you need any of the following types of connectivity:

  • Connections between virtual networks.
  • Point-to-site connections.
  • Multisite connections.
  • Coexistence with an Azure ExpressRoute gateway.
Key features of route-based VPN gateways in Azure include:
  • Supports IKEv2.
  • Uses any-to-any (wildcard) traffic selectors.
  • Can use dynamic routing protocols, where routing/forwarding tables direct traffic to different IPsec tunnels.
    When configured to use dynamic routing, the source and destination networks are not statically defined because they are in policy-based VPNs, or even in route-based VPNs with static routing. Instead, data packets are encrypted based on network routing tables that are created dynamically using routing protocols such as Border Gateway Protocol (BGP).

    Azure VPN gateways only support the use pre-shared key method of authentication. Both route-based and policy-based types also rely on Internet Key Exchange (IKE) in either version 1 or version 2 and Internet Protocol Security (IPsec). IKE is used to set up a security association (an agreement of the encryption) between two endpoints. This association is then passed to the IPsec suite, which encrypts and decrypts data packets encapsulated in the VPN tunnel.

VPN gateway requirements

The following Azure resources need to be present before you can deploy an operational VPN gateway:

  • Virtual network. An Azure virtual network with enough address space for the additional subnet that you'll need for the VPN gateway. The address space for this virtual network must not overlap with the on-premises network that you'll be connecting to.
  • GatewaySubnet. A subnet called GatewaySubnet for the VPN gateway. Requires at least a /27 address mask. This subnet cannot be used for any other services.
  • Public IP address. A Basic-SKU dynamic public IP address if using a non-zone-aware gateway. This address provides a public-routable IP address as the target for your on-premises VPN device. This IP address is dynamic, but it won't change unless you delete and re-create the VPN gateway.
  • Local network gateway. Create a local network gateway to define the on-premises network's configuration: where the VPN gateway will connect and what it will connect to. This configuration includes the on-premises VPN device's public IPv4 address and the on-premises routable networks. This information is used by the VPN gateway to route packets that are destined for on-premises networks through the IPsec tunnel.
    When these prerequisite components are present, you can create the virtual network gateway to route traffic between the virtual network and the on-premises datacenter or other virtual networks. After the virtual network gateway is deployed, you can then create a connection resource to create a logical connection between the VPN gateway and the local network gateway:
  • The connection is made to the on-premises VPN device's IPv4 address as defined by the local network gateway.
  • The connection is made from the virtual network gateway and its associated public IP address.
You can configure multiple connections, up to the limit defined by the SKU, for each Azure VPN gateway.

High availability

    Even though you only see one VPN gateway resource in Azure, VPN gateways are deployed as two instances of managed virtual machines in an active/standby configuration. When planned maintenance or unplanned disruption affects the active instance, the standby instance automatically assumes responsibility for connections without any user or administrator intervention. Connections are interrupted during this failover, but they're typically restored within a few seconds for planned maintenance and within 90 seconds for unplanned disruptions.

    Azure VPN gateways support the BGP routing protocol, which allows you to also deploy VPN gateways in an active/active configuration. In this configuration, you assign a unique public IP address to each instance. You then create separate tunnels from the on-premises device to each IP address. You can extend the high availability by deploying an more VPN device on-premises.

When to use Azure VPN Gateway

   Azure VPN gateways allow you to set up the following connections:

  • Connect on-premises datacenters to Azure virtual networks through a site-to-site connection.
  • Connect individual devices to Azure virtual networks through a point-to-site connection.
  • Connect Azure virtual networks to other Azure virtual networks through a network-to-network connection.
Azure VPN gateways are suitable for Adatum for the following reasons:
  • It's necessary to provide remote workers with secure access to applications running on IaaS virtual machines that are hosted on Azure virtual networks. It can be accomplished by configuring point-to-site VPNs that connect to an Azure VPN gateway on the same virtual network that hosts the IaaS virtual machine workloads. It will allow secure access to the applications without exposing those applications directly to hosts on the internet.
  • It's necessary to provide workers at Adatum's main office with access to the applications running on the IaaS virtual machines in Azure. In this case, a site-to-site VPN configured between the main office and the Azure VPN gateway on the IaaS workload virtual network will allow secure access without exposing the VM workloads directly to hosts on the internet.
    Because Adatum is likely to deploy more subnets on its virtual networks and to also deploy more IaaS workloads on virtual networks around the world in the future, you should ensure that Adatum deploys a route-based VPN gateway rather than a policy-based VPN gateway. Route-based VPN gateways support adding subnets to existing virtual networks and VPN connections between Azure virtual networks.

When not to use Azure VPN Gateway

    Azure VPN Gateway is not always the best solution for connecting an on-premises environment to the cloud. Azure ExpressRoute is a dedicated, high-speed private connection between an on-premises network and Microsoft cloud services, including Microsoft Azure and Microsoft 365. Azure ExpressRoute is most suitable for organizations that need to quickly and reliably transfer large volumes of data between their on-premises workload and their cloud workload.

    Adatum should choose Azure ExpressRoute over Azure VPN Gateway as a method of connecting your on-premises environment to Azure if the following factors are true:

  • Workers at Adatum require low-latency connections to resources in Microsoft clouds.
  • Workers at Adatum require a high-bandwidth connection to resources in Microsoft clouds.
  • Compliance regulations require that all data transmitted between Adatum's on-premises location and Microsoft cloud not pass across a public network.

Komentar

Posting Komentar

Postingan populer dari blog ini

Implement CI/CD with Azure DevOps

-
Gambar
  Introduction      Imagine you are part of a team of data engineers who are collaborating on one or more notebooks within a development environment, using Azure Databricks. When you are ready to deploy your changes to production, you must coordinate with an operations team to copy the notebooks over to a production Azure Databricks workspace since company policy dictates that you and your team are not allowed to manually copy the changed files over. This process causes bottlenecks and extra work. Leadership has asked you to find an automated process that incorporates version control, automated testing capabilities, and controls for deployment approvals if needed. Automated testing and deployment is a common practice in software development. However, those same principles also apply to data engineering and data science. Data engineers and data scientists need to collaborate on parts of the system and be able to deploy to production without constantly relying on opera...
Baca selengkapnya

Introduction to ASP.NET Core SignalR

-
Gambar
  What is ASP.NET Core SignalR?      All internet-connected applications are composed of servers and clients. Clients rely on servers for data, and their primary mechanism for receiving data is through making Hypertext Transfer Protocol (HTTP) requests. Some client applications require data that changes frequently.      ASP.NET Core SignalR provides an API for creating server-to-client remote procedure calls (RPCs). RPCs invoke functions on clients from the server-side .NET Core code. There are several supported platforms, each with its own client SDK. Because of this, the programming language being invoked by RPC calls varies.      It's helpful to familiarize yourself with the common terminology that's associated with SignalR. In this unit, you'll learn what SignalR components are required in a server application versus those in client applications. Additionally, you'll gain an understanding of the various duplex communication mechanism...
Baca selengkapnya

Microsoft Security, Compliance, and Identity : Describe the concepts of security, compliance, and identity

-
Gambar
    Everybody, and each gadget, has an personality that can be utilized to get to assets. Personality is the way in which individuals and things are recognized on your corporate arrange, and within the cloud. Being certain almost who or what is getting to your organization’s data and other assets may be a essential portion of securing your environment. This zone is known as personality and get to administration, and is made up of two key steps: confirming and authorizing identities. In this module, you'll learn why identity is imperative in securing corporate resources. After completing this module, you will be able to: Describe the concept of identity as a security perimeter. Understand the difference between authentication and authorization. Describe identity-related services. Describe common identity attacks      A few of the foremost common sorts of security dangers that organizations confront nowadays are personality assaults. These assaults are outlined to...
Baca selengkapnya