Deploying NetMotion Mobility in Azure

NetMotion MobilityOne of the many advantages NetMotion Mobility offers is that it requires no proprietary hardware to deliver its advanced capabilities and performance. It is a software solution that can be installed on any physical or virtual Windows server. This provides great deployment flexibility by allowing administrators to deploy this remote access solution on their existing virtual infrastructure, which is much less costly than investing in dedicated hardware or virtual appliances.

Cloud Deployment

As customers begin moving their traditional on-premises infrastructure to the cloud, it’s good to know that NetMotion Mobility is fully supported in popular public cloud platforms such as Microsoft Azure. Installing and configuring Mobility on a server in Azure requires a few important changes to a standard Azure VM deployment however. Below is detailed guidance for installing and configuring NetMotion Mobility on a Windows Server 2016 virtual machine hosted in the Microsoft Azure public cloud.

Azure Networking Configuration

Before installing the NetMotion Mobility software, follow the steps below to configure the Azure VM with a static public IP address and enable IP forwarding on the internal network interface.

  1. In the Azure management portal, select the NetMotion Mobility virtual machine and click Networking.
  2. Click on the public-facing network interface.
  3. In the Settings section click IP configurations.
  4. In the IP configurations section click on the IP configuration for the network interface.
  5. In the Public IP address setting section click Enabled for the Public IP address.
  6. Click Configure required settings for the IP address.
  7. Click Create New.
  8. Enter a descriptive name and select Static as the assignment method.
    Deploying NetMotion Mobility in Azure
  9. Click OK
  10. Click Save.Deploying NetMotion Mobility in AzureNote: The process of saving the network interface configuration takes a few minutes. Be patient!
  11. Note the public IP address, as this will be used later during the Mobility configuration.
  12. Close the IP address configuration blade.
  13. In the IP forwarding settings section click Enabled for IP forwarding.Deploying NetMotion Mobility in Azure
  14. Click Save.

NetMotion Mobility Installation

Proceed with the installation of NetMotion Mobility. When prompted for the external address, enter the public IP address created previously.

Deploying NetMotion Mobility in Azure

Next choose the option to Use pool of virtual IP addresses. Click Add and enter the starting and ending IP addresses, subnet prefix length, and default gateway and click OK.

Deploying NetMotion Mobility in Azure

Complete the remaining NetMotion Mobility configuration as required.

Azure Routing Table

A user defined routing table must be configured to ensure that NetMotion Mobility client traffic is routed correctly in Azure. Follow the steps below to complete the configuration.

  1. In the Azure management portal click New.
  2. In the Search the Marketplace field enter route table.
  3. In the results section click Route table.
  4. Click Create.
  5. Enter a descriptive name and select a subscription, resource group, and location.
  6. Click Create.

Deploying NetMotion Mobility in Azure

Once the deployment has completed successfully, click Go to resource in the notifications list.

Deploying NetMotion Mobility in Azure

Follow the steps below to add a route to the route table.

  1. In the Settings sections click Routes.
  2. Click Add.
  3. Enter a descriptive name.
  4. In the Address prefix field enter the subnet used by mobility clients defined earlier.
  5. Select Virtual appliance as the Next hop type.
  6. Enter the IP address of the NetMotion Mobility server’s internal network interface.
  7. Click OK.Deploying NetMotion Mobility in Azure
  8. Click Subnets.
  9. Click Associate.
  10. Click Choose a virtual network and select the network where the NetMotion Mobility gateway resides.
  11. Click Choose a subnet and select the subnet where the NetMotion Mobility gateway’s internal network interface resides.
  12. Click OK.

Note: If clients connecting to the NetMotion Mobility server need to access resources on-premises via a site-to-site gateway, be sure to associate the route table with the Azure gateway subnet.

Azure Network Security Group

A network security group must be configured to allow inbound UDP port 5008 to allow external clients to reach the NetMotion Mobility gateway server. Follow the steps below to create and assign a network security group.

  1. In the Azure management portal click New.
  2. In the Search the Marketplace field enter network security group.
  3. In the results section click Network security group.
  4. Click Create.
  5. Enter a descriptive name and select a subscription, resource group, and location.
  6. Click Create.

Deploying NetMotion Mobility in Azure

Once the deployment has completed successfully, click Go to resource in the notifications list.

Deploying NetMotion Mobility in Azure

Follow the steps below to configure the network security group.

  1. In the Settings section click Inbound security rules.
  2. Click Add.
  3. Enter 5008 in the Destination port ranges field.
  4. Select UDP for the protocol.
  5. Select Allow for the action.
  6. Enter a descriptive name.
  7. Click OK.
    Deploying NetMotion Mobility in Azure
  8. Click Network Interfaces.
  9. Click Associate.
  10. Select the external network interface of the NetMotion Mobility gateway server.

Summary

After completing the steps above, install the client software and configure it to use the static public IP address created previously. Alternatively, configure a DNS record to point to the public IP address and specify the Fully Qualified Domain Name (FQDN) instead of the IP address itself.

Additional Resources

Enabling Secure Remote Administration for the NetMotion Mobility Console

NetMotion Mobility Device Tunnel Configuration

NetMotion Mobility as an Alternative to Microsoft DirectAccess

NetMotion Mobility and Microsoft DirectAccess Comparison Whitepaper

NetMotion and Microsoft DirectAccess On-Demand Webinar

Always On VPN and Windows Routing and Remote Access Service (RRAS)

Always On VPN and Windows Routing and Remote Access Service (RRAS)

As I’ve written about in the past, Windows 10 Always On VPN has many advantages over DirectAccess. One of the most important features is that Always On VPN is completely infrastructure independent. Always On VPN is implemented entirely on the client side, so there is no reliance on Windows infrastructure servers at all. In theory, you could deploy an Always On VPN solution using an entirely third-party backend infrastructure. This is crucial because many organizations already have security infrastructure in place today. However, there are still some compelling reasons to choose Windows Server 2016 as the VPN server to support Windows 10 Always On VPN.

Considerations for Windows Server

Windows Server 2016 includes a very capable VPN server in the Routing and Remote Access Service (RRAS) role. Using Windows Server 2016 RRAS will meet the requirements for many deployment scenarios. RRAS also provides some unique advantages too. The following are some important considerations for choosing RRAS for VPN.

Easy to Deploy

The RRAS role in included in all Windows server network operating systems and can be enabled easily using the GUI or PowerShell. RRAS is mature and well-documented, making installation and configuration simpler. In fact, all of the Microsoft Windows 10 Always On VPN documentation guidance references RRAS.

Reduced Costs

No investment in proprietary hardware is required, because RRAS runs on Windows Server 2016 and can be deployed on existing virtual infrastructure. Deploying additional RRAS virtual machines enables quick and efficient scaling up of the solution without the need to deploy additional expensive hardware. Importantly, RRAS requires no additional per-client or per-device licensing. In addition, RRAS can be managed using existing Windows administration skill sets and does not require dedicated, and often expensive solution-specific expertise.

Modern Protocol Support

RRAS includes support for modern VPN protocols such as Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). IKEv2 is the protocol of choice or most deployments, and is required for supporting the device tunnel. SSTP is a firewall-friendly protocol that ensures remote Windows clients can connect from anywhere. Layer Two Tunneling Protocol over IPsec (L2TP/IPsec) and Point-to-Point Tunneling Protocol (PPTP) are also supported for legacy client compatibility.

Summary

Although Windows 10 Always On VPN can be implemented using third-party VPN servers, it’s important not to overlook Windows server either. Windows Server 2016 RRAS has some important advantages over third-party infrastructure. RRAS is mature and well understood, with an abundance of published documentation available. Leveraging RRAS eliminates the need for costly proprietary hardware and client licensing, while at the same time reducing administrative overhead and streamlining support. RRAS also includes native support for modern VPN protocols, ensuring reliable client connectivity from any location.

Additional Resources

3 Important Advantages of Windows 10 Always On VPN over DirectAccess 

Windows 10 Always On VPN and the Future of DirectAccess 

5 Things DirectAccess Administrators Should Know About Always On VPN 

Outlook Offline over DirectAccess on Windows 10

Outlook Offline over DirectAccess on Windows 10You may encounter a scenario in which Outlook on Windows 10 reports that it is working offline while connected remotely via DirectAccess. The Network Connectivity Status Indicator (NCSI) shows DirectAccess is in a connected state and all other internal resources are accessible.

Outlook Offline over DirectAccess on Windows 10

This is caused by the default settings of the IP-HTTPS tunnel interface on the DirectAccess server not advertising a default route for connected DirectAccess clients. To resolve this issue, enable default route advertising for IP-HTTPS on each DirectAccess server in the enterprise by running the following PowerShell command.

Get-NetIPInterface | Where-Object {$_.InterfaceAlias -eq “IPHTTPSInterface”} | Set-NetIPInterface -AdvertiseDefaultRoute Enabled -PassThru

Outlook Offline over DirectAccess on Windows 10

In the past I’ve heard reports of this setting being overwritten after group policy refresh. Recent testing on Windows Server 2016 does not show this behavior, however. Please report any results you may have in the comments below. Thanks!