Multi-Tenant VPN with Windows Server 2012 R2

Multi-Tenant VPN with Windows Server 2012 R2

  • Comments 2
  • Likes

In the previous blogs we looked at how cloud service providers can reduce their capital expenditure (CAPEX) and operation expenditure (OPEX) by deploying multi-tenant site-to-site (S2S) VPN & multi-tenant routing using Border Gateway Protocol (BGP) with Windows Server 2012 R2. In this blog we will examine details of how remote access dial-in (point-to-site or machine to site) VPN can be enabled for multiple tenants with overlapping IP address space using a shared Windows Server 2012 R2 multi-tenant VPN server.

Hybrid-networking enables the enterprises, Small & Medium Business (SMB) to deploy their workloads in clouds. Microsoft Windows Server 2012 introduced Hyper-V Network Virtualization (HNV) that enables cloud service providers to deploy Virtual Machines (VMs) of multiple tenants with overlapping IP addresses on a shared physical infrastructure. The workloads are hosted in cloud service provider datacenter (or cloud) can be accessed from inside the enterprise corporate network via site-to-site (S2S) Virtual Private Network (VPN).

When employees of enterprises have to access workloads in cloud from outside the corporate network, they VPN to their enterprise VPN gateway and access workloads via S2S VPN. If the enterprise VPN gateway is not available due to disaster or any outage, employees of enterprises can access their workloads by directly establishing a VPN connection with the cloud service provider gateway.

Businesses that do not have their own Remote Access (Dial-in) VPN infrastructure can allow their employees to VPN to cloud service provider gateway and access workloads in cloud directly and workloads back in their business premises via S2S VPN. Employees of infrastructure–less businesses who have their entire workloads in cloud need to VPN to cloud service provider to access their internal workloads.

Note: - when we say “access the workloads”, it mean “the client applications like SQL client querying a database server”. Cloud service provider can allow access to the actual VMs for diagnostics or management to the admins of business via Remote Desktop Protocol or similar mechanisms.

In this blog, we will understand how remote access (dial-in) VPN requirements of two organizations Woodgrove Bank and Contoso Ltd are fulfilled by cloud service provider Fabrikam using multi-tenancy capability of Windows Server 2012 R2 RemoteAcccess role.

image

In the above diagram a gateway VM dedicated to Contoso enables VPN connections from employees of Contoso to connect to their virtual network in Fabrikam. Interface IfCi1 connects to Contoso virtual network in Fabrikam while VPN clients connect over interface IfCe1. After VPN connection is complete, packets to Contoso virtual subnet 10.0.0.0/24 are sent to Contoso GW VM in Fabrikam network. TCP/IP stack on GW VM routes the packets to interface IfCi1 which delivers the packets inside Contoso subnet 10.0.0.0/24. And in the opposite direction, when packets are to be routed from Subnet 10.0.0.0/24 to VPN client they are forwarded to interface IfCi1 and TCP/IP stack on GW VM routes the packets over VPN tunnel via interface IfCe1.

Similarly another GW VM dedicated for Woodgrove enables VPN client to connect to Woodgrove virtual network in Fabrikam. There are two problems with this approach:

  1. The number of gateways increase linearly as the number of tenants increase. Note that for high availability cloud service provider would have to deploy two gateway VMs per tenant.
  2. Each tenant requires at least one public IP address on the public interface of the GW VM. If multiple tenant gateways are deployed behind a NAT device with one public IP, the destination port to which the tenants connect to should be different for different tenants. Hence VPN tunnels that rely on SSL port 443 cannot be used by the tenants. If the port changes to some other random port, the packets may be dropped by firewalls in coffee-shops or access points from which tenants connect (the very reason why port 443 is used for SSTP so that they can traverse firewalls).

Fabrikam would prefer deploying a gateway that could be shared across multiple tenants similar to deploying multiple tenant virtual networks over a shared physical network using Hyper Network Virtualization (HNV) or VLAN. (You can refer to the blog here for more details of multi-tenant stack and its integration with HNV. The blog here has details of how to integrate multi-tenant stack with VLAN.)

Multi-tenant VPN

Multi-Tenant RRAS VPN feature introduced in Windows Server 2012 R2 enables multiple customers’ VPN connections with overlapping IP addresses to be terminated on a single virtual machine. This eliminates the requirement of separate VPN gateways to handle traffic from VPN connections of different enterprises. This feature helps reduce the cost of cloud service providers who cater to multiple customers as deploying multiple gateway VPN Servers per customer increases the cost thus creating a scalability restraint. The service provider can deploy this feature using a single public IP address per VPN gateway that is used by all the tenants on the gateway.

The network diagram below represents the Fabrikam cloud service provider network and its edge gateway described above when deployed with multi-tenant architecture of the Windows Server 2012 R2.

image

Here, the multi-tenancy of VPN gateways is achieved by creating multiple “compartments” (or Routing Domains, where one compartment corresponds to one tenant) in the gateway VM, each having its own unique Virtual Subnet ID (VSID) to provide isolation from other compartments. These compartments can have overlapping IP Addresses and other network configurations while still logically separating them from other compartments configured on the system. The network setup presented here is discussed in the next section.

Network setup

The Fabrikam edge gateway host is connected to two network adapters (NIC1 and NIC2) for internal and external communication and a single gateway virtual machine is configured on the host. This gateway VM is configured with multi-tenancy support and as shown above, it communicates with the internal (Cloud) and external (internet) networks via the virtual switches configured on the physical NICs.

The gateway virtual machine is configured with two different compartments Contoso and Woodgrove corresponding to the respective tenants and these compartments are configured with Multi-Tenant RemoteAccess VPN. The two compartments Contoso and Woodgrove have their own external (IfCR1 and IfWR1 resp.) and internal interfaces (IfCi1 and IfWi1 resp.), which can have overlapping IP Addresses assigned to them. Both these compartments will route traffic between their own internal and external interfaces unaware of any other compartments by virtue of the multitenant TCP/IP stack.

The Contoso and Woodgrove VPN clients will be connecting to their corresponding Cloud Gateways via internet and trying to access the resources (subnets / application servers) hosted by the cloud service provider Fabrikam.

How it all works

Before we look at how multi-tenant VPN works, let’s understand in detail how VPN in RemoteAccess works -

VPN clients connect to the public interface of the VPN server. On the VPN server a new “RAS dial-in interface” is created. After connecting to the VPN Server, all VPN clients are assigned an IP Address from the pool configured on the VPN Server. The traffic to and from the IP Addresses of this pool is routable to the corporate network and allows the VPN Clients to access the corporate resources behind the VPN Server.

Now, as indicated above, each compartment in the new “multi-tenant” capable gateway VM is configured with a Virtual Subnet ID (or VSID), which uniquely identifies the traffic meant for each routing domain. So when a Contoso employee dials the VPN connection to the public interface of the cloud service provider’s gateway VPN Server, the Multi-tenant aware RemoteAccess server validates the user credentials and identifies the corresponding tenant. It then creates a new RAS dial-in interface in Contoso compartment and assigns the client an IP address as configured in the Contoso compartment’s Routing Domain. The VPN tunnel is created between the client and the newly created RAS dial-in interface for traffic exchange.

Once the RAS dial-in interface and VPN tunnel are created, the data packets received from VPN client are forwarded to the corresponding hosted virtual network (vNet) using the assigned a VSID associated with the tenant. Similarly, when the traffic in the opposite direction (vNet to VPN client) meant for the client reaches the internal v-switch of the Fabrikam’s Cloud Gateway, it looks for the destination Routing Domain ID based on the incoming packet’s VSID. It happens to be the Contoso compartment, so the packet is injected in Contoso compartment. Once the packet lands in contoso compartment the /32 route on dial-in interface causes packets to be routed on dial-in interface that delivers packets to the corresponding VPN tunnel.

So, with the multi-tenant stack enhancements as described above, the cloud service providers can use a single VM for the VPN Server with a single external IP Address for all the different tenants. The VPN Clients for these tenants can then connect to the gateway using the tenant specific credentials, which then help the multi-tenant VPN server identify the tenant and assign a unique VSID to the data packets for that tenant. Also, as the different tenants have the corresponding port assigned to them, a single external IP Address can distribute the client data within different tenant compartments based on these port mappings. All this results in reduced deployment cost (lesser hardware, public IP Address requirement, lower maintenance, management cost) for cloud service providers and translates into lesser cost for enterprise customers.

Multi-tenant VPN configuration

This section lists the system prerequisites, various components and their configuration how-to for setting up a Multi-tenant RemoteAccess VPN Server.

System Prerequisites

Following are the system prerequisites for configuration of a Multi-Tenant RemoteAccess VPN Server –

  • One host machine running Microsoft Windows Server 2012 R2 and configured with Hyper-V
  • Two physical Network Adapters on the Host machine
    1. One connected to Internet (External Interface)
    2. One connected to Corp Network (Internal Interface)
  • One instance of virtual machine configured on the Hyper-V, running Windows Server 2012 R2 and configured with more than one Routing Domains (either using PowerShell cmdlets or via SC-VMM). This VM acts as the Multi-Tenant VPN Gateway.
  • The Virtual Machine must be connected to both the Internal and External Networks via Virtual Switches configured with the two Network Adapters on Host Machine.

Multi-tenant VPN components

The complete Multi-Tenant VPN configuration can be divided into following components –

  • Host Computer
    1. Multi-tenant stack/Compartment configuration
  • Virtual machine (configuration for each compartment / routing domain / tenant)
    1. Multi-Tenant VPN Installation and activation
    2. Multi-Tenant gateway VPN Server prerequisites configuration
    3. RADIUS configuration
    4. VPN User configuration

Compartment configuration (Host computer)

Before configuration of RemoteAccess VPN Server on the virtual machine, required compartments or Routing Domains need to be configured / added. This configuration is done at the physical host. The complete process is as follows –

  1. To configure multiple routing domains, MultiTenancy needs to be enabled on the Virtual Network Adapter (this will be the network adapter connected to internal network) connected with the target virtual machine and then mapping(s) of the desired routing domains need to be created / added on this Multi-Tenancy enabled Virtual Network Adapter. This can be done using the following cmdlets -

    # Macro Definitions

    $MTGW_VM_Name = <Name of the VM hosting Multi-tenant RemoteAccess VPN Server, e.g. – “MT-VPN-GW”>

    $MT_NIC_Name = <Name of the Virtual Network Adapter connected to cloud service provider network, e.g. – “MultiTenantNic”>

    $ContosoRoutingDomainGuid = <A unique GUID for Contoso’s Routing Domain, e.g. – “{12345678-1000-2000-3000-123456780001}”>

    $ContosoVSID_GW = <A unique Virtual Subnet ID for Contoso, e.g. – “6001”>

    $WoodgroveRoutingDomainGuid = “{12345678-1000-2000-3000-123456780002}”

    $WoodgroveVSID_GW = “7001”

    # Enabling Multi-tenancy on the backend network adapter

    Set-VmNetworkAdapterIsolation –VMName $MTGW_VM_Name –VMNetworkAdapterName $MT_NIC_Name –MultiTenantStack on –IsolationMode NativeVirtualSubnet

    #Configure Routing Domains

    Add-VmNetworkAdapterRoutingDomainMapping –VMName $MTGW_VM_Name –VMNetworkAdapterName $MT_NIC_Name –RoutingDomainId $ContosoRoutingDomainGuid –RoutingDomainName “Contoso” –IsolationId $ContosoVSID_GW –IsolationName “Contoso-Subnet”

    Add-VmNetworkAdapterRoutingDomainMapping –VMName $MTGW_VM_Name –VMNetworkAdapterName $MT_NIC_Name –RoutingDomainId $WoodgroveRoutingDomainGuid –RoutingDomainName “Woodgrove” –IsolationId $WoodgroveVSID_GW –IsolationName “Woodgrove-Subnet”
  2. Once the Add-VmNetworkAdapterRoutingDomainMapping cmdlet is executed for all the required Routing Domains, same number of compartments are created for the Virtual Machine. This can be verified by executing the following cmdlet on an elevated PowerShell window on the Virtual Machine

    PS C:\> Get-NetCompartment

     

    CompartmentId                : 1

    CompartmentDescription : Default Compartment

    CompartmentGuid            : {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

     

    CompartmentId                : 2

    CompartmentDescription : Contoso

    CompartmentGuid            : {12345678-1000-2000-3000-123456780001}

     

    ...

This completes the multi-tenant host configuration.

Multi-Tenant VPN Installation and activation (Virtual Machine)

Once the routing domains are ready, the RemoteAccess VPN Service can be configured on the virtual machine and it can be configured for these routing domains. This section provides a step-by-step account of this configuration.

RemoteAccess installation with Multi-Tenancy support

Following PowerShell cmdlets shall install RemoteAccess with Multi-Tenancy support –

# Install RemoteAccess with MultiTenancy

Add-WindowsFeature -Name Remoteaccess -IncludeAllSubFeature –IncludeManagementTools

 

ipmo remoteaccess

 

Install-RemoteAccess –MultiTenancy

 

# Check RemoteAccess Installation

Get-RemoteAccess

Enable VPN on all the target Routing Domains

Windows Server 2012 R2 only supports VPN Multi-tenancy for SSTP and IKEv2 tunneling protocols and the examples in this setup use IKEv2.

Following PowerShell cmdlets enable VPN on Multi-Tenant RemoteAccess service –

# Enable RemoteAccess “VPN”

Enable-RemoteAccessRoutingDomain -Name “Contoso” -Type Vpn –PassThru

Enable-RemoteAccessRoutingDomain -Name “Woodgrove” -Type Vpn –PassThru

 

# Test whether routing domains are enabled or not

Get-RemoteAccessRoutingDomain

Start RemoteAccess service

Use the following PowerShell cmdlets to check if RemoteAccess service is running and start if not running –

# Check if RemoteAccess Service is “Running”

Get-Service “RemoteAccess”

 

# Start RemoteAccess Service if not “Running”

Start-Service “RemoteAccess”

Multi-Tenant RemoteAccess VPN Server prerequisites configuration

The above steps install RemoteAccess and enable VPN for both the routing domains. But still the VPN prerequisites and other components need to be configured for the RemoteAccess VPN Server.

Following are the prerequisites for the configuration of a RemoteAccess VPN Server in a Multi-Tenant deployment –

  1. A valid IPv4 Address Range for the IP Addresses to be assigned to VPN clients
  2. Tenant Name to be used for the Routing Domain
  3. A valid IPv6 Address Prefix representing the pool of IP Addresses to be assigned to VPN Clients (optional, only for IPv6 deployments)

IPv4 Address Range and Tenant Name are mandatory configurations for a RemoteAccess VPN Server. Optionally, IPv6 prefix can also be configured in the case IPv6 addressing is being used.

Tenant Name can be any user defined name or regular expression (“contoso” or “.*contoso.*”) to identify the Tenant / Routing Domain, but it has to be unique across the Routing Domains. Tenant Name is used to identify the tenant of a VPN client – the credentials1 supplied by the VPN user are forwarded to the NPS / RADIUS to perform authentication, which returns the authentication packet with the user credentials and an additional (optional) ClassID attribute.

1Note: - VPN client credential format is usually a regular expression containing the Tenant Name and the corporate username. E.g. an employee John Doe from Contoso Ltd. can dial the VPN connection using one of the following expression for username – JohnDoe@Contoso OR Contoso\JohnDoe

This optional ClassID attribute can be configured for VPN client authentication in the multi-tenant environment. This parameter rewrites the authentication packet with extra tenant information configured in ClassID (e.g. TenantName=”contoso” will be appended), which is then used to identify the tenant compartment (instead of the actual credential regular expression).

For example – let us assume that the compartment is configured with the TenantName “Contoso” and the NPS connection request policy checks for all incoming VPN client requests for the regular expression *@CTS.com and then rewrite this authentication packet with ClassID TenantName = “Contoso” to match with the compartment’s TenantName. Now, the user connecting using the credentials JohnDoe@CTS.com will match the NPS policy and will be authenticated with the configured mechanism. In addition to the authentication, the ClassID attribute TenantName=”Contoso” and will be overwritten in the returned packet and will be used for identifying the destination tenant compartment.

Note: - Tenant identification is performed through ClassID attribute “if configured” in NPS, otherwise through the credentials provided in the authentication packet.

The following PowerShell cmdlet can be used to configure these prerequisites –

Set-RemoteAccessRoutingDomain –Name “Contoso” –IPAddressRange 11.11.11.1, 11.11.11.200 –IPv6Prefix 2001:db8:a::/64 –TenantName “Contoso

Set-RemoteAccessRoutingDomain –Name “Woodgrove” –IPAddressRange 11.11.11.1, 11.11.11.200 –IPv6Prefix 2001:db8:a::/64 –TenantName “Woodgrove

RADIUS configuration

RemoteAccess VPN Server needs to have a RADIUS Server configured for client authentication. This can be done by using an external RADIUS (not shown in the setup), or by configuring a local RADIUS.

  1. Remote RADIUS – Configure the remote RADIUS Server(s) available in your network for client authentication and make sure the remote RADIUS Server is configured with appropriate Access Policies.
  2. The PowerShell cmdlet to add a RADIUS Server if no RADIUS has been configured is –

    Set-VpnAuthType –Type ExternalRadius –RadiusServer “TestRadiusServer1” –SharedSecret “Password

    The PowerShell cmdlet to add a RADIUS Server if one or more RADIUS server are already configured is –

    Set-RemoteAccessRADIUS –Type ExternalRadius –ServerName “TestRadiusServer2” –Purpose Authentication –SharedSecret “Password

  3. Local RADIUS – If a local RADIUS Server is being used, configure the corresponding NPS policies
    1. Configure the Network Policies for VPN Clients –> The Network Policies can be configured via NPS GUI and easy to use wizards or via netsh commands.
    2. The actual steps for configuration via GUI can be found in this TechNet page.

      A sample netsh command for network policy configuration is –

      # Add Network Policy “GrantFullAccess”

      netsh nps add np Name="GrantFullAccess" state = "enable" processingorder = "2" policysource = "2" conditionid = "0x40" conditiondata = "^1$|^79617$" profileid = "0x1fd9" profiledata = "0x0" profileid = "0x1005" profiledata = "True" profileid = "0x100f" profiledata = "True" profileid = "0x100a" profiledata = "19000000000000000000000000000000" profiledata = "1A000000000000000000000000000000" profileid = "0x1009" profiledata = "0x5" profiledata = "0x3" profiledata = "0x9" profiledata = "0x4" profiledata = "0xa" profileid = "0x1faf" profiledata = "0x0" profileid = "0x1fc8" profiledata = "FALSE" profileid = "0x7" profiledata = "0x1" profileid = "0x6" profiledata = "0x2" profileid = "0xffffffaa" profiledata = "0x32" profileid = "0xffffffa9" profiledata = "0x78"

      More information on the netsh cmdlets for Network Access policies is available here

    3. Configure the Connection Request Policies for the VPN Clients à The Connection Request Policies can be configured via NPS GUI and easy to use wizards or via netsh commands.

    The actual steps for configuration via GUI can be found in this TechNet page.

    A sample netsh command for network policy configuration is –

    # Add Connection Request Policy “Microsoft RRAS CR Policy for Contoso”

    netsh nps add crp name = “Microsoft RRAS CR Policy for Contoso” state = “Enable” processingorder = “2” policysource = “2” conditioned = “0x1” conditiondata = “CONTOSO.*” conditioned = “0x40” conditiondata = “^1$|^79617$” profileid = “0x100a” profiledata = “1A000000000000000000000000000000” profiledata = “0D000000000000000000000000000000” profileid = “0x1009” profiledata = “0x5” profileid = “0x1025” profiledata = “0x1” profileid = “0x1fb0” profiledata = “TRUE” profileid = “0x19” profiledata = “TenantName = Contoso”

    More information on the netsh cmdlets for Network Access policies is available here.

  4. Windows Authentication – If Windows Authentication is being used, then the RemoteAccess VPN Server (virtual machine) needs to be either domain joined or should have the VPN Users configured locally for authentication. Following command can be used for adding a new local user –

    # Add a local user for VPN

    net use “TestVPNUser” * /add

This completes the Multi-Tenant VPN configuration. If there are multiple Routing Domains, repeat the above process for the required routing domains.

Note – The Network Access Policies and Connection Request Policies configured here use only the basic authentication for users (EAP-MSCHAPv2 authentication). If a more advanced configuration is required, please refer to this TechNet article.

Note – A simple automated configuration script for Multi-Tenant VPN is available at TechNet script center, which can perform all of the steps described above.

PowerShell cmdlet references

Cmdlet

Description

Get-NetCompartment

This cmdlet retrieves all the Routing Domains configured on the system

Get-RemoteAccess

Retrieves the status of RemoteAccess installation

Install-RemoteAccess –MultiTenancy

This cmdlet installs RemoteAccess in MultiTenancy mode

Get-RemoteAccessRoutingDomain

This cmdlet retrieves the RemoteAccess configuration of the Routing Domains in a multi-tenant system

Enable-RemoteAccessRoutingDomain -Type “Vpn”

This cmdlet enables VPN for the specified Routing Domain

Set-RemoteAccessRoutingDomain

Configures / modifies the RemoteAccess configuration for the specified Routing Domain

Add-RemoteAccessRADIUS

Adds the specified RADIUS Server to the list of supported RADIUS Servers for RemoteAccess

Set-VpnAuthType –Type ExternalRadius

Configures a Remote RADIUS for VPN Client authentication

Note: - For details on all the RemoteAccess PowerShell cmdlets, please visit the Technet library.

Summary

With windows server 2012 R2, a cloud service provider will be able to deploy a single gateway for providing point-to-site VPN connectivity to multiple tenant virtual networks. This will provide the cloud service providers with an easily scalable deployment model and the reduced number of edge gateways and external IP Address requirements will help greatly reduce the total cost of offering VPN connectivity service for the enterprise customers.

We’d love to hear any feedback or comments on these new capabilities!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Great article, very detailed and useful. The configuration should be more intuitive and made easier in future versions/updates. It is too cumbersome now. Also, can you also provide guidance around sizing the VPN gateway, how many sessions each VPN gateway VM can manage.