Intro

Setting up a VPN to your on-premise network

Documentation

• Tutorial: Create a Site-to-Site connection in the Azure portal

• Highly Available cross-premises and VNet-to-VNet connectivity

• VPN Gateway FAQ

• Connect an on-premises network to Azure

Tips and Tidbits

• Each virtual network can have only one VPN gateway.

• An Azure VPN gateway is made up of these elements:

  • Virtual network gateway

  • Local network gateway

  • Connection

  • Gateway subnet

• S2S: if you want to connect a virtual network to another virtual network, the address space cannot overlap with the other virtual network.

Design and implement Azure VPN Gateway

• Design and implement Azure VPN Gateway

• Azure VPN Gateway provides an endpoint for incoming connections from on-premises environments.

• A VPN gateway can send encrypted traffic between the two networks.

• Each virtual network can have only one VPN gateway.

  • All connections to that VPN gateway share the available network bandwidth.

• VPN gateways can also be used for connections between virtual networks in Azure.

• Within each virtual network gateway there are two or more virtual machines (VMs).

  • These VMs have been deployed to a special subnet that you specify, called the gateway subnet.

  • They contain routing tables for connections to other networks, along with specific gateway services.

• Select a gateway SKU satisfies your requirements based on the types of workloads, throughputs, features, and SLAs.

  • 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.

    • You must delete the Basic SKU VPN gateway and recreate it with the new SKU.

    • The Aggregate Throughput Benchmark for a VPN Gateway is S2S + P2S combined.

  • Basic and VpnGw1 SKUs are only supported in Generation1. VpnGw4 and VpnGw5 SKUs are only supported in Generation2.

• VPN types

• There are two VPN types:

• PolicyBased VPNs were previously called static routing gateways

  • Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the IPsec policies configured with the combinations of address prefixes between your on-premises network and the Azure VNet.

  • The policy (or traffic selector) is usually defined as an access list in the VPN device configuration.

  • PolicyBased VPNs can only be used on the Basic gateway SKU,

  • You can have only 1 tunnel when using a PolicyBased VPN.

  • You can only use PolicyBased VPNs for S2S connections

• RouteBased VPNs were previously called dynamic routing gateways

  • 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).

• a P2S connection requires a RouteBased VPN type

• Once a virtual network gateway has been created, you can't change the VPN type.

• Gateway subnet

• The gateway subnet contains the IP addresses that the virtual network gateway VMs and services use.

• Never deploy anything else (for example, additional VMs) to the gateway subnet.

• The gateway subnet must be named GatewaySubnet to work properly.

• The IP addresses in the gateway subnet are allocated to the gateway VMs and gateway services.

  • Some configurations require more IP addresses than others.

  • we recommend that you create a gateway subnet of /27 or larger (/27, /26 etc.)

• Create the Local Network Gateway

• The local network gateway typically refers to the on-premises location.

  • You give the site a name by which Azure can refer to it, then specify the IP address or FQDN of the on-premises VPN device for the connection.

  • You also specify the IP address prefixes that will be routed through the VPN gateway to the VPN device.

  • The address prefixes you specify are the prefixes located in the on-premises network.

• Configure the on-premises VPN device

• To configure your VPN device, you will 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.

• 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.
    
    
    

Open

Site To Site (S2S) Connection

• Connect networks with Site-to-site VPN connections

• Site-to-Site (IPsec/IKE VPN tunnel) configurations are between your on-premises location and Azure.

  • This means that you can connect from any of your computers located on your premises to any virtual machine or role instance within your virtual network.

Open

Steps:

• Create a virtual network, VNET1

  • If a duplicate address range exists on both sides of the VPN connection, traffic will route in an unexpected way.

  • Additionally, if you want to connect this virtual network to another virtual network, the address space cannot overlap with the other virtual network.

• Create a VPN gateway for your VNET1

  • A VPN gateway (or virtual network gateway) is a resource that provides a virtual VPN appliance for the VNet.

  • It is responsible for routing traffic from the on-premises network to the
    VNet.

  • The virtual network gateway uses specific subnet called the gateway subnet.

  • The gateway subnet is part of the virtual network IP address range that you specify when configuring your virtual network.

  • It contains the IP addresses that the virtual network gateway resources and services use.

  • When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet

  • Select Gateway SKUs

• Create a local network gateway

  • The local network gateway is a specific object that represents your on-premises location (the site) for routing purposes.

  • An abstraction of the on-premises VPN appliance

• Create a VPN connection

• Verify the connection

• Connect to a virtual machine

• Connect an on-premises network to Azure

• How to configure BGP on Azure VPN Gateways

• BGP is the standard routing protocol commonly used in the Internet to exchange routing and reachability information between two or more networks.

• BGP enables the Azure VPN gateways and your on-premises VPN devices, called BGP peers or neighbors, to exchange "routes" that will inform both gateways on the availability and reachability for those prefixes to go through the gateways or routers involved.

• BGP can also enable transit routing among multiple networks by propagating routes a BGP gateway learns from one BGP peer to all other BGP peers.

Point-To-Point as a failover for ExpressRoute

• Configure ExpressRoute and Site-to-Site coexisting connections

• The ExpressRoute circuit is always the primary link.

• Data flows through the Site-to-Site VPN path only if the ExpressRoute circuit fails.

• if Express Route exists then GatewaySubnet already exists

• ExpressRoute virtual network gateways can use the following SKUs:

  • Standard

  • HighPerformance

  • UltraPerformance

• ExpressRoute-VPN Gateway coexist configurations are not supported on the Basic SKU.

Point-to-Site (VPN over SSTP)

• Connect devices to networks with Point-to-site VPN connections

•  

• Point-to-Site (VPN over SSTP) configurations let you connect from a single computer from anywhere to anything located in your virtual network.

  • It uses the Windows in-box VPN client.

  • As part of the Point-to-Site configuration, you install a certificate and a VPN client configuration package, which contains the settings that allow your computer to connect to any virtual machine or role instance within the virtual network.

Point-to-site VPN can use one of the following protocols:

• OpenVPN® Protocol, an SSL/TLS based VPN protocol.

  • A TLS VPN solution can penetrate firewalls, since most firewalls open TCP port 443 outbound, which TLS uses.

  • OpenVPN can be used to connect from Android, iOS (versions 11.0 and above), Windows, Linux, and Mac devices (macOS versions 10.13 and above).

• Secure Socket Tunneling Protocol (SSTP), a proprietary TLS-based VPN protocol.

  • A TLS VPN solution can penetrate firewalls, since most firewalls open TCP port 443 outbound, which TLS uses.

  • SSTP is only supported on Windows devices. Azure supports all versions of Windows that have SSTP (Windows 7 and later).

• IKEv2 VPN, a standards-based IPsec VPN solution.

  • IKEv2 VPN can be used to connect from Mac devices (macOS versions 10.11 and above).

User Authentication

• The user must be authenticated before Azure accepts a P2S VPN connection.

  • Authenticate using native Azure certificate authentication

    • When using the 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

    • The root certificate is required for the validation and must be uploaded to Azure.

  • Authenticate using native Azure Active Directory authentication

    • Native Azure AD authentication is only supported for OpenVPN protocol and Windows 10 and requires the use of the Azure VPN Client.

  • Authenticate using Active Directory (AD) Domain Server

    • AD Domain 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 AD server.

    • The RADIUS server is deployed either on-premises or in your Azure VNet.

      • During authentication, the Azure VPN Gateway passes authentication messages back and forth between the RADIUS server and the connecting device.

      • Thus, the Gateway must be able to communicate with the RADIUS server.

      • The RADIUS server can also integrate with AD certificate services.

      • This lets you use the RADIUS server and your enterprise certificate deployment for P2S certificate authentication as an alternative to the Azure certificate authentication.

• About Point-to-Site VPN routing

• If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again in order for the changes to be applied to the client.

• Multi-peered VNETs

• VNet1 has “Allow gateway transit” and VNet2 and VNet4 have “Use remote gateways” enabled.

Redundant Site to Site (S2S) VPN Gateways

• VPN Gateway redundancy

• 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

• The switch over will cause a brief interruption.

  • For planned maintenance, the connectivity should be restored within 10 to 15 seconds.

  • For unplanned issues, the connection recovery will be longer, about 1 to 3 minutes in the worst case.

• Multiple on-premises VPN devices

• 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 will be forwarded through these tunnels simultaneously.

• You must use Equal-cost multi-path routing (ECMP).

• this setup guards against failures or interruptions on your on-premises network and VPN devices.

• Active-active VPN gateways

• You can create an Azure VPN gateway in an active-active configuration, where both instances of the gateway VMs will establish S2S VPN tunnels to your on-premises VPN device

• In this configuration, each Azure gateway instance will have a unique public IP address, and each will establish an IPsec/IKE S2S VPN tunnel to your on-premises VPN device specified in your local network gateway and connection.

• 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.

• the traffic from your Azure virtual network to your on-premises network will be routed through both tunnels simultaneously,

• Dual-redundancy: active-active VPN gateways for both Azure and on-premises networks

• The result is a full mesh connectivity of 4 IPsec tunnels between your Azure virtual network and your on-premises network.

• All gateways and tunnels are active from the Azure side, so the traffic will be spread among all 4 tunnels simultaneously, although each TCP or UDP flow will again follow the same tunnel or path from the Azure side

• Two public IP addresses in the on-premises data center, and two public IP addresses for each virtual network gateway

• 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 4 tunnels between the two VNets

• BGP is optional unless transit routing over the VNet-to-VNet connection is required.

Troubleshoot Azure VPN Gateway

• validate network throughput from the on-premises resources to an Azure virtual machine (VM). Validate VPN throughput to a virtual network - Azure VPN Gateway.

• Troubleshoot Azure point-to-site connection problems - Azure VPN Gateway.

• Troubleshoot an Azure site-to-site VPN connection that cannot connect - Azure VPN Gateway.

• Community-suggested third-party VPN or firewall device settings for Azure VPN Gateway.

• Troubleshoot Azure VPN Gateway using diagnostic logs

•  

• The following logs are available in Azure:

• To establish a cross-premises connection, you need to create a Local Network Gateway to represent your on-premises VPN device, and a Connection to connect the Azure VPN gateway with the local network gateway

• You can have more than one virtual network gateway servicing a VNET (as shown above).

• PowerShell script to build Active-Active configuration: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-activeactive-rm-powershell

Point To Site (P2S) Virtual Networks

• Configure a Point-to-Site VPN connection using Azure certificate authentication: Azure portal

• Point-to-Site connections do not require a VPN device or a public-facing IP address. 

• P2S creates the VPN connection over either SSTP (Secure Socket Tunneling Protocol), or IKEv2.

  • For more information about Point-to-Site VPN, see About Point-to-Site VPN

• Point-to-site native Azure certificate authentication connections use the following items:

  • A RouteBased VPN gateway.

  • The public key (.cer file) for a SSL root certificate, which is uploaded to Azure. Once the certificate is uploaded, it is considered a trusted certificate and is used for authentication.

    • You don't need to export the private key.

    • If you aren't using an enterprise certificate solution, you can create a self-signed root certificate.

    • Otherwise, the certificates you create won't be compatible with your P2S connections and clients will receive a connection error when they try to connect.

  • A client certificate that is generated from the root certificate. The client certificate installed on each client computer that will connect to the VNet. This certificate is used for client authentication.

    • Make sure the client certificate was exported as a .pfx along with the entire certificate chain (which is the default) and its private key!

    • Otherwise, the SSL root certificate information isn't present on the client computer and the client won't be able to authenticate properly.

    • Install client certificates for P2S certificate authentication connections

  • VPN client configuration. The VPN client is configured using VPN client configuration files. These files contain the necessary information for the client to connect to the VNet. The files configure the existing VPN client that is native to the operating system. Each client that connects must be configured using the settings in the configuration files.

  • The Basic gateway SKU does not support IKEv2 or RADIUS authentication. If you plan on having Mac clients connect to your virtual network, do not use the Basic SKU.

P2S - Multiple peered VNets

• P2S - Multiple peered VNets

• In this example, the Point-to-Site VPN gateway connection is for VNet1.

  • VNet1 is peered with VNet2.

  • VNet 2 is peered with VNet3.

  • VNet1 is peered with VNet4.

  • There is no direct peering between VNet1 and VNet3.

  • VNet1 has “Allow gateway transit” and VNet2 and VNet4 have “Use remote gateways” enabled.

  • Clients using Windows can access directly peered VNets (VNet1, VNet2 and VNet3), but the VPN client must be downloaded again if any changes are made to VNet peering or the network topology.

  • Non-Windows clients can access directly peered VNets.

  • Access is not transitive (can’t access VNet3!) and is limited to only directly peered VNets.

VPN Routing

• Policy-based (static-routing) gateway: Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the combinations of address prefixes between your on-premises network and the Azure VNet. The policy (or Traffic Selector) is usually defined as an access list in the VPN configuration.

• Route-based (dynamic-routing) gateway: Route-based 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 selectors for route-based VPNs are configured as any-to-any (or wild cards).

• A gateway type cannot be changed from policy-based to route-based, or from route-based to policy-based. To change a gateway type, the gateway must be deleted and recreated.

Forced Tunneling

To force all traffic from a VNET to go through an on-prem VPN: Configure forced tunneling

• Forced tunneling lets you redirect or "force" all Internet-bound traffic back to your on-premises location via a Site-to-Site VPN tunnel for inspection and auditing.

• This is a critical security requirement for most enterprise IT policies.

• Forced tunneling can be configured by using Azure PowerShell. It can't be configured using the Azure portal.

• The Mid-tier and Backend subnets are forced tunneled.

• Any outbound connections from these two subnets to the Internet will be forced or redirected back to an on-premises site via one of the Site-to-site (S2S) VPN tunnels.

• Redirecting traffic to an on-premises site is expressed as a Default Route to the Azure VPN gateway.

• Forced tunneling must be associated with a VNet that has a route-based VPN gateway.

  • You need to set a "default site" among the cross-premises local sites connected to the virtual network. (Set-AzureRmVirtualNetworkGatewayDefaultSite)

  • Also, the on-premises VPN device must be configured using 0.0.0.0/0 as traffic selectors.