Always On VPN and RRAS in Azure

Always On VPN and RRAS in AzureWhen deploying Windows 10 Always On VPN, it may be desirable to host the VPN server in Microsoft’s Azure public cloud. Recently I wrote about Always On VPN deployment options in Azure, and in that post I indicated that deploying Windows Server and the Routing and Remote Access Service (RRAS) was one of those options. Although not formally supported by Microsoft, RRAS is often deployed in Azure because it is cost-effective, easy to manage, and provides flexible scalability.

Supportability

It’s important to state once again that although it is possible to successfully deploy Windows Server with RRAS in Azure to support Always On VPN, as of this writing it is not a formally supported workload. If the administrator makes the decision to deploy RRAS in Azure, they must also accept that Microsoft may refuse to assist with troubleshooting in this specific deployment scenario.

Always On VPN and RRAS in Azure

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

Azure Prerequisites

The configuration of RRAS is identical to on-premises, with a few additional steps required by Azure infrastructure.

Windows Server

RRAS can be configured on any Windows Server virtual machine supported in Microsoft Azure. As with on-premises deployments, Server GUI and Core are supported. Domain-join is optional. The server can be deployed with one network interface or two.

Public IP

A public IP address must be assigned to the VPN server’s external network interface, or the internal interface if the VPN server is configured with a single network adapter. The IP address can be static or dynamic. When using a dynamic IP address, configure a CNAME record in DNS that points to the name configured for the IP address in Azure. If using a static IP address, an A host record can be configured pointing directly to the IP address.

Network Security Group

A Network Security Group (NSG) must be configured and assigned to the VPN server’s external or public-facing network interface that allows the following protocols and ports inbound.

  • TCP port 443 (SSTP)
  • UDP port 500 (IKEv2)
  • UDP port 4500 (IKEv2 NAT traversal)

RRAS in Azure

Below are the infrastructure requirements for supporting Windows Server RRAS VPN in Azure.

Client IP Subnet

Static IP address pool assignment must be used with RRAS. Using DHCP for VPN client IP address assignment in Azure is not supported and will not work. The IP subnet assigned to VPN clients by RRAS must be unique and not overlap with any existing Azure VNet subnets. If more than one VPN server is deployed, each server should be configured to assign a unique subnet for its clients.

IP Forwarding

IP forwarding must be enabled on the VPN server’s internal network interface. Follow the steps below to enable IP forwarding.

1. In the Azure portal, open the properties page for the internal network interface for the VPN server.
2. Click IP configurations in the navigation pane.
3. Click Enabled next to IP forwarding.
4. Click Save.

Always On VPN and RRAS in Azure

Routing

Azure must be configured to route IP traffic from VPN clients back to the VPN server. Follow the steps below to create and assign a routing table in Azure.

1. Click Create Resource.
2. Enter “Route Table” in the search field and press Enter.
3. Click Route Table.
4. Click Create.
5. Enter a descriptive name for the route table in the Name field.
6. Choose an appropriate subscription from the Subscription drop-down list.
7. Select the resource group where the VPN server(s) reside.
8. Select the best location to deploy the route table resource from the Location drop-down list.
9. If the administrator wants to have the VPN client IP subnet route information published automatically, select Enabled for Virtual network gateway route propagation.
10. Click Create.

Always On VPN and RRAS in Azure

Once complete, follow the steps below to define the route for VPN clients.

1. Open the properties page for the route table.
2. Click Routes in the navigation pane.
3. Click Add.
4. Enter a descriptive name in the Route name filed.
5. Enter the IP subnet assigned to VPN clients in the Address prefix field.
6. Select Virtual appliance from the Next hop type drop-down list.
7. Enter the IPv4 address assigned to the VPN server’s internal network interface in the Next hop address field.
8. Click Ok.
9. Repeat the steps above for each VPN server configured in Azure.

Always On VPN and RRAS in Azure

Finally, follow the steps below to assign the route table to an Azure VNet subnet.

1. Open the properties page for the route table.
2. Click Subnets in the navigation pane.
3. Click Associate.
4. Click Virtual network.
5. Choose the appropriate Azure VNet.
6. Click Subnet.
7. Choose an Azure VNet subnet to assign the route table to.
8. Click Ok.
9. Repeat the steps above to assign the route table to any Azure VNet subnet that must be accessible by VPN clients. If VPN clients need access to on-premises resources via Azure site-to-site gateway, assign the route table to the Azure VPN gateway subnet.

Always On VPN and RRAS in Azure

Note: Azure only supports the assignment of one route table per subnet. If a route table is currently assigned, the VPN client subnet route can be added to an existing route table, if necessary.

Summary

Administrators have many choices when it comes to support Always On VPN connections hosted in Azure. RRAS on Windows Server can be an effective solution, assuming you can live without formal support. If having a formally supported solution is a hard requirement, consider deploying Always On VPN using the native Azure VPN gateway or another third-part Network Virtual Appliance (NVA).

Additional Information

Windows 10 Always On VPN with Azure Gateway

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN Multisite with Azure Traffic Manager

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

After installing and configuring DirectAccess in Windows Server 2019 you may encounter an error message indicating that IP-HTTPS is not working properly. Looking at the Operations Status overview in the Dashboard of the Remote Access Management console shows that the IP-HTTPS interface is in error.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

IP-HTTPS Route Error

Viewing the detailed Operations Status shows the following error message.

Error: The IP-HTTPS route does not have published property enabled.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Missing Route

Looking at the routing table on the DirectAccess server reveals that a route to the client IPv6 prefix is indeed missing.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Resolution

To resolve this error message, add the client IPv6 route to the DirectAccess server’s routing table and publish it. This is accomplished by running the following PowerShell commands on the DirectAccess server.

$IPv6prefix = (Get-RemoteAccess).ClientIPv6Prefix
New-NetRoute -AddressFamily IPv6 -DestinationPrefix $IPv6prefix -InterfaceAlias “Microsoft IP-HTTPS Platform Interface” -Publish Yes

Next, restart the Remote Access Management service (RaMgmtSvc) using the following PowerShell command.

Restart-Service RaMgmtSvc -PassThru

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Once complete, refresh the management console and the IP-HTTPS error message should be resolved and the operations status should state that it is now working properly.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

 

Additional Information

SSL Certificate Conisderations for DirectAccess IP-HTTPS

DirectAccess Expire IP-HTTPS Certificate and Error 0x800b0101

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

%d bloggers like this: