Design and implement hybrid networking Flashcards
Virtual Private Network (VPN)
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.
One option for connecting an on-premises network to an Azure virtual network is a VPN connection. A VPN gateway provides an endpoint for incoming connections to an Azure virtual network.
Azure VPN Gateways
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.
- A virtual network gateway is composed of two or more special VMs that are deployed to a specific subnet called the gateway subnet. Virtual network gateway VMs host routing tables and run specific gateway services. (managed automatically by Azure)
When you’re planning a VPN gateway, there are three architectures to consider:
* Point to site over the internet
* Site to site over the internet
* Site to site over a dedicated network, such as Azure ExpressRoute
- Use Virtual WAN if you need more than 30 S2S VPN tunnels.
- The resizing of VpnGw SKUs is allowed within the same generation, except resizing of the Basic SKU.
- On a single tunnel, a maximum of 1-Gbps throughput can be achieved.
VPN Gateway types
The VPN type that you choose depends on the connection topology that you want to create. For example, a P2S connection requires a RouteBased VPN type. A VPN type can also depend on the hardware that you’re using. S2S configurations require a VPN device. Some VPN devices only support a certain VPN type.
- Once a virtual network gateway is created, you can’t change the VPN type. You must delete the virtual network gateway and create a new one.
There are two VPN types:
PolicyBased
Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the IPsec policies. The policy (or traffic selector) is defined as an access list in the VPN device configuration. The value for a PolicyBased VPN type is PolicyBased. When using a PolicyBased VPN, keep in mind the following limitations:
- Policy based VPNs which support IKEv1 protocols can be used with Basic Gateway SKUs only.
- You can have only one tunnel when using a PolicyBased VPN.
- You can only use PolicyBased VPNs for S2S connections, and only for certain configurations. Most VPN Gateway configurations require a RouteBased VPN.
RouteBased
VPNs use “routes” in the IP forwarding or routing table to direct packets into their corresponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the tunnels. The policy (or traffic selector) for RouteBased VPNs are configured as any-to-any (or wild cards). The value for a RouteBased VPN type is RouteBased.
Gateway Subnet
VPN Gateways require a gateway subnet. You can create a Gateway subnet before you create a VPN gateway, or you can create it during the creation of the VPN Gateway. The gateway subnet contains the IP addresses that the virtual network gateway VMs and services use.
- Never deploy anything else (for example, more VMs) to the gateway subnet.
- The gateway subnet must be named GatewaySubnet to work properly
- ExpressRoute/VPN Gateway coexist configuration requires a larger gateway subnet than most other configurations.
- While you can create a gateway subnet as small as /29, we recommend that you create a gateway subnet of /27 or larger.
Local Network Gateway
The local network gateway typically refers to the on-premises location.
Configure the on-premises VPN device
To configure your VPN device, you need:
- A shared key. The same shared key that you specify when creating the VPN connection.
- The public IP address of your VPN gateway. The IP address can be new or existing.
Create the VPN Connection
Once your VPN gateways are created, you can create the connection between them. If your VNets are in the same subscription, you can use the portal.
Name. Enter a name for your connection.
Connection type. Select Site-to-Site (IPSec) from the drop-down.
Shared key (PSK). In this field, enter a shared key for your connection. You can generate or create this key yourself. In a site-to-site connection, the key you use is the same for your on-premises device and your virtual network gateway connection.
High availability options for VPN connections
To provide better availability for your VPN connections, there are a few options available:
1. VPN Gateway redundancy (Active-standby)
Every Azure VPN gateway consists of two instances in an active-standby configuration. For any planned maintenance or unplanned disruption that happens to the active instance, the standby instance would take over (failover) automatically and resume the S2S VPN or VNet-to-VNet connections. The switch over causes a brief interruption. For planned maintenance, the connectivity should be restored within 10 to 15 seconds. For unplanned issues, the connection recovery is longer, about 1 to 3 minutes in the worst case. For P2S VPN client connections to the gateway, the P2S connections are disconnected, and the users need to reconnect from the client machines.
2 Multiple on-premises VPN devices
You can use multiple VPN devices from your on-premises network to connect to your Azure VPN gateway. This configuration provides multiple active tunnels from the same Azure VPN gateway to your on-premises devices in the same location. There are some requirements and constraints:
- You need to create multiple S2S VPN connections from your VPN devices to Azure.
- The local network gateways corresponding to your VPN devices must have unique public IP addresses in the GatewayIpAddress property.
- BGP is required for this configuration. Each local network gateway representing a VPN device must have a unique BGP peer IP address specified in the BgpPeerIpAddress property.
- You should use BGP to advertise the same prefixes of the same on-premises network prefixes to your Azure VPN gateway, and the traffic is forwarded through these tunnels simultaneously.
- You must use Equal-cost multi-path routing (ECMP).
- Each connection is counted against the maximum number of tunnels for your Azure VPN gateway, 10 for Basic and Standard SKUs, and 30 for HighPerformance SKU.
In this configuration, the Azure VPN gateway is still in active-standby mode, so the same failover behavior and brief interruption occurs.
3. Active-active VPN gateways
You can create an Azure VPN gateway in an active-active configuration, where both instances of the gateway VMs establish S2S VPN tunnels to your on-premises VPN device.
- Both VPN tunnels are part of the same connection. You need to configure your on-premises VPN device to accept or establish two S2S VPN tunnels to those two Azure VPN gateway public IP addresses.
- Because the Azure gateway instances are in active-active configuration, the traffic from your Azure virtual network to your on-premises network is routed through both tunnels simultaneously
4. Dual-redundancy: active-active VPN gateways for both Azure and on-premises networks
Here you create and set up the Azure VPN gateway in an active-active configuration and create two local network gateways and two connections for your two on-premises VPN devices. The result is a full mesh connectivity of 4 IPsec tunnels between your Azure virtual network and your on-premises network.
- This topology requires two local network gateways and two connections to support the pair of on-premises VPN devices, and BGP is required to allow the two connections to the same on-premises network.
5. Highly Available VNet-to-VNet
The same active-active configuration can also apply to Azure VNet-to-VNet connections. You can create active-active VPN gateways for both virtual networks, and connect them together to form the same full mesh connectivity of four tunnels between the two VNets.
Troubleshoot Azure VPN Gateway using diagnostic logs
Using diagnostic logs, you can troubleshoot multiple VPN gateway related events including configuration activity, VPN Tunnel connectivity, IPsec logging, BGP route exchanges, Point to Site advanced logging.
There are several diagnostic logs you can use to help troubleshoot a problem with your VPN Gateway.
* GatewayDiagnosticLog - Contains diagnostic logs for gateway configuration events, primary changes, and maintenance events.
* TunnelDiagnosticLog - Contains tunnel state change events. Tunnel connect/disconnect events have a summarized reason for the state change if applicable.
* RouteDiagnosticLog - Logs changes to static routes and BGP events that occur on the gateway.
* IKEDiagnosticLog - Logs IKE control messages and events on the gateway.
* P2SDiagnosticLog - Logs point-to-site control messages and events on the gateway.
Use Azure Monitor to analyze the data collected in the diagnostic logs.
Site-to-site VPN connections
A site-to-site (S2S) VPN gateway connection lets you create a secure connection to your virtual network from another virtual network or a physical network.
Using this architecture offers several benefits, including:
- Simplifying configuration and maintenance.
- Encrypting data and traffic between the on-premises gateway and the Azure gateway.
- Allowing for future network requirements.
Point-to-site VPN connections
A Point-to-Site (P2S) VPN gateway connection lets you create a secure connection to your virtual network from an individual client computer. A P2S connection is established by starting it from the client computer.
- P2S VPN is also a useful solution to use instead of S2S VPN when you have only a few clients that need to connect to a VNet.
Point-to-site protocols
* OpenVPN® Protocol, an SSL/TLS based VPN protocol.
* Secure Socket Tunneling Protocol (SSTP), a proprietary TLS-based VPN protocol.
* IKEv2 VPN, a standards-based IPsec VPN solution.
The user must be authenticated before Azure accepts a P2S VPN connection. There are two mechanisms that Azure offers to authenticate a connecting user.
1. Authenticate using native Azure certificate authentication
A client certificate on the device is used to authenticate the connecting user. Client certificates are generated from a trusted root certificate and then installed on each client computer.
2. Authenticate using native Microsoft Entra ID authentication
Native authentication allows users to connect to Azure using their Microsoft Entra ID credentials. Native authentication is only supported for OpenVPN protocol and Windows 10 and requires the use of the Azure VPN Client.
- With this authentication, you can use conditional access and multifactor authentication (MFA) features for VPN
3. Authenticate using Active Directory Domain Services
This authentication is a popular option because it allows users to connect to Azure using their organization domain credentials. It requires a RADIUS server that integrates with the server.
- The RADIUS server is deployed either on-premises or in your Azure VNet.
- A RADIUS server can also integrate with other external identity systems, such as multifactor authentication.
Configure point-to-site clients
Users use the native VPN clients on Windows and Mac devices for P2S. Azure provides a VPN client configuration zip file that contains settings required by these native clients to connect to Azure.
The zip file also provides the values of some of the important settings on the Azure side that you can use to create your own profile for these devices. Some of the values include the VPN gateway address, configured tunnel types, routes, and the root certificate for gateway validation.
Connect remote resources by using Azure Virtual WANs
Azure Virtual WAN is a networking service that brings many networking, security, and routing functionalities together to provide a single operational interface. Some of the main features include:
- Branch connectivity (via connectivity automation from Virtual WAN Partner devices such as SD-WAN or VPN CPE).
- Site-to-site VPN connectivity.
- Remote user VPN connectivity (point-to-site).
- Private connectivity (ExpressRoute).
- Intra-cloud connectivity (transitive connectivity for virtual networks).
- VPN ExpressRoute inter-connectivity.
- Routing, Azure Firewall, and encryption for private connectivity.
To configure an end-to-end virtual WAN, you create:
- Virtual WAN
- Hub
- Hub virtual network connection
- Hub-to-hub connection
- Hub route table
Virtual WAN SKUs
1. Basic
* Hub type: Basic
* Available configurations: Site-to-site VPN only
2. Standard
* Hub type: Standard
* Available configurations: ExpressRoute, User VPN (P2S), VPN (site-to-site). Inter-hub and VNet-to-VNet transiting through the virtual hub, Azure Firewall, NVA in a virtual WAN
Hub private address space
A virtual hub is a Microsoft-managed virtual network. The hub contains various service endpoints to enable connectivity. From your on-premises network (vpnsite), you can connect to a VPN gateway inside the virtual hub, connect ExpressRoute circuits to a virtual hub, or even connect mobile users to a point-to-site gateway in the virtual hub.
- The hub is the core of your network in a region. Multiple virtual hubs can be created in the same region.
- The minimum address space is /24 to create a hub.
Gateway scale
A hub gateway isn’t the same as a virtual network gateway that you use for ExpressRoute and VPN Gateway. For example, when using Virtual WAN, you don’t create a site-to-site connection from your on-premises site directly to your VNet. Instead, you create a site-to-site connection to the hub. The traffic always goes through the hub gateway. Virtual WAN lets your VNets take advantage of scaling easily through the virtual hub and the virtual hub gateway.
Gateway scale units determine the aggregate throughput of the gateway in the virtual hub. Each type of gateway scale unit (site-to-site, user-vpn, and ExpressRoute) is configured separately.
Connect cross-tenant VNets to a Virtual WAN hub
You can use Virtual WAN to connect a VNet to a virtual hub in a different tenant. This architecture is useful if you have client workloads that must be connected to be the same network but are on different tenants.
Before you can connect a cross-tenant VNet to a Virtual WAN hub, you must have the following configuration already set up:
- A Virtual WAN and virtual hub in the parent subscription.
- A virtual network configured in a subscription in the remote tenant.
- Nonoverlapping address spaces in the remote tenant and address spaces within any other VNets already connected to the parent virtual hub.
Virtual Hub routing
The routing capabilities in a virtual hub are provided by a router that manages all routing between gateways using Border Gateway Protocol (BGP). A virtual hub can contain multiple gateways such as a Site-to-site VPN gateway, ExpressRoute gateway, Point-to-site gateway, Azure Firewall.
- This router also provides transit connectivity between virtual networks that connect to a virtual hub and can support up to an aggregate throughput of 50 Gbps.
- These routing capabilities apply to Standard Virtual WAN customers.
Hub route table
You can create a virtual hub route and apply the route to the virtual hub route table. You can apply multiple routes to the virtual hub route table.
Network Virtual Appliance (NVA) in a Virtual Hub
NVAs are deployed directly into a Virtual WAN hub and have an externally facing public IP address. Once VNets are connected to the virtual hub, NVAs enable transitive connectivity throughout the organization’s Virtual WAN.
Manage an NVA in a Virtual Hub
The NVAs available in the Azure Marketplace can be deployed directly into a virtual hub and nowhere else. Each is deployed as a Managed Application, which allows Azure Virtual WAN to manage the configuration of the NVA. They can’t be deployed within an arbitrary VNet.
When you create an NVA in the Virtual WAN hub, like all Managed Applications, there are two Resource Groups created in your subscription.
Customer Resource Group - This contains an application placeholder for the Managed Application. Partners can use this resource group to expose whatever customer properties they choose here.
* Managed Resource Group - Customers can’t configure or change resources in this resource group directly.
Create the Network Virtual Appliance in the hub
For this example, we’re creating a Barracuda CloudGen WAN Gateway.
- Locate the Virtual WAN hub you created in the previous step and open it.
- Find the Network Virtual Appliances tile and select the Create link.
- On the Network Virtual Appliance blade, select “Barracuda CloudGen WAN”, then select the Create button.
- The Azure Marketplace offers the Barracuda CloudGen WAN gateway. Read the terms, then select the Create button when you’re ready.
- On the Basics page you need to provide the following information: Subscription, Resource Group, Region, Application Name, Managed Resource Group.
- Select the Next: CloudGen WAN gateway button.
- Provide the following information here: Virtual WAN Hub, NVA Infrastructure Units, Token
NVA Infrastructure Units
When you create an NVA in the Virtual WAN hub, you must choose the number of NVA Infrastructure Units you want to deploy it with. An NVA Infrastructure Unit is a unit of aggregate bandwidth capacity for an NVA in the Virtual WAN hub.
