Cloudflare Public DNS Resolver Now Available

Cloudflare Public DNS Resolver Now AvailableCloudflare has become a nearly ubiquitous cloud service provider in recent years, fronting many of the busiest web sites on the Internet. They provide tremendous value both in terms of security and performance for their customers. They have a wide array of solutions designed to provide better security, including optimized SSL/TLS configuration and Web Application Firewall (WAF) capabilities. Their DDoS mitigation service is second to none, and their robust Content Delivery Network (CDN) ensures optimal loading of content for web sites anywhere in the world.

Public DNS Resolver

Recently Cloudflare announced their first consumer service, a public DNS resolver that is free for general use. It offers exceptional performance and supports many of the latest DNS security and privacy enhancements such as DNS-over-TLS. Cloudflare has also pledged not to write DNS queries to disk at all and not to store them for more than 24 hours to further ensure privacy for their customers.

Cloudflare Public DNS Resolver Now Available

DNS Security Controls

What Cloudflare DNS is lacking today is granular security enforcement to provide additional protection for client computers outside the firewall. For example, public DNS resolvers from OpenDNS and Quad9 have built-in security features that use threat intelligence to identify and block DNS name resolution requests for domains that are known to be malicious or unsafe. OpenDNS has the added benefit of providing more granularity for setting policy, allowing administrators to select different filtering levels and optionally to create custom policies to allow or block individually selected categories. With OpenDNS, security administrators can also manage domains individually by manually assigning allow or block to specific, individual domains as necessary.

Recommended Use Cases

Cloudflare DNS clearly offers the best performance of all public DNS resolvers today, which makes it a good candidate for servers that rely heavily on DNS for operation. Mail servers come to mind immediately, but any system that performs many forward and/or reverse DNS lookups would benefit from using Cloudflare DNS. Cloudflare DNS can also be used by client machines where better performance and enhanced privacy are desired.

Quad9 DNS is a good choice for client computers where additional security is required. OpenDNS is the best choice where the highest level of security is required, and where granular control of security and web filtering policies is necessary.

Additional Information

Cloudflare DNS
Quad9 DNS
OpenDNS
Dnsperf.com

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

NetMotion Mobility for DirectAccess Administrators – Split vs. Force TunnelingDirectAccess employs a split tunneling network model by default. In this configuration, only network traffic destined for the internal network (as defined by the administrator) is tunneled over the DirectAccess connection. All other network traffic is routed directly over the Internet.

Force Tunneling Use Cases

For a variety of reasons, administrators may want to configure DirectAccess to use force tunneling, requiring all client traffic be routed over the DirectAccess connection, including public Internet traffic. Commonly this is done to ensure that all traffic is logged and, importantly, screened and filtered to enforce acceptable use policy and to prevent malware infection and potential loss of data.

DirectAccess and Force Tunneling

Enabling force tunneling for DirectAccess is not trivial, as it requires an on-premises proxy server to ensure proper functionality when accessing resources on the public Internet. You can find detailed guidance for configuring DirectAccess to use force tunneling here.

NetMotion Mobility and Force Tunneling

With NetMotion Mobility, force tunneling is enabled by default. So, if split tunneling is desired, it must be explicitly configured. Follow the steps below to create a split tunneling policy.

Create a Rule Set

  1. Open the NetMotion Mobility management console and click Policy > Policy Management.
  2. Click New.
  3. Enter a descriptive name for the new rule set.
  4. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Create a Rule

  1. Click New.
  2. Enter a descriptive name for the new rule.
  3. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Define an Action

  1. Click on the Actions tab.
  2. In the Addresses section check the box next to Allow network traffic for address(es)/port(s).NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  3. In the Base section select Pass through all network traffic.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Define the Internal Network

  1. In the Policy rule definition section click the address(es)/port(s) link.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  2. Click Add.
  3. In the Remote Address column select Network Address.
  4. Enter the network prefix and prefix length that corresponds to the internal network.
  5. Click Ok.
  6. Repeat the steps above to add any additional internal subnets, as required.
  7. Click Ok.
  8. Click Save.
  9. Click Save.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Assign the Policy

  1. Click on the Subscribers tab.
  2. Choose a group to assign the policy to. This can be users, groups, devices, etc.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  3. Click Subscribe.
  4. Select the Split Tunneling policy.
  5. Click Ok.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Validation Testing

With split tunneling enabled the NetMotion Mobility client will be able to securely access internal network resources over the Mobility connection, but all other traffic will be routed over the public Internet. To confirm this, first very that internal resources are reachable. Next, open your favor Internet search engine and enter “IP”. The IP address you see should be the IP address of the client, not the on-premises gateway.

Summary

I’ve never been a big fan of force tunneling with DirectAccess. Not only is it difficult to implement (and requires additional infrastructure!) the user experience is generally poor. There are usability issues especially with captive portals for Wi-Fi, and performance often suffers. In addition, enabling force tunneling precludes the use of strong user authentication with one-time passwords.

With NetMotion Mobility, force tunneling is on by default, so no configuration changes are required. The user experience is improved as NetMotion Mobility intelligently recognizes captive portals. Performance is much better too. In addition, NetMotion Mobility is more flexible, allowing for the use of OTP authentication with force tunneling. Also, with NetMotion Mobility force tunneling is not a global setting. You can selectively apply force tunneling to users and/or groups as necessary.

Additional Information

NetMotion Mobility as an Alternative for Microsoft DirectAccess

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Enabling Secure Remote Administration for the NetMotion Mobility Console

NetMotion Mobility Device Tunnel Configuration

 

Deleting an Always On VPN Device Tunnel

Deleting an Always On VPN Device TunnelWindows 10 Always On VPN supports both a user tunnel for corporate network access, and a device tunnel typically used to provide pre-logon network connectivity and to support manage out scenarios. The process of testing Always On VPN is often an iterative one involving trial and error testing to fine tune the configuration parameters to achieve the best experience. As a part of this process it will often be necessary to delete a connection at some point. For the user tunnel the process is simple and straightforward. Simply disconnect the session and delete the connection in the UI.

Deleting an Always On VPN Device Tunnel

Deleting a device tunnel connection presents a unique challenge though. Specifically, there is no VPN connection in the UI to disconnect and remove. To delete an Always On VPN device tunnel, open an elevated PowerShell window and enter the following command.

Get-VpnConnection -AllUserConnection | Remove-VpnConnection -Force

If the device tunnel is connected when you try to remove it, you will receive the following error message.

The VPN connection [connection_name] cannot be removed from the global user connections. Cannot
delete a connection while it is connected.

Deleting an Always On VPN Device Tunnel

The device tunnel must first be disconnected to resolve this issue. Enter the following command to disconnect the device tunnel.

rasdial.exe [connection_name] /disconnect

Remove the device tunnel connection using PowerShell once complete.

Deleting an Always On VPN Device Tunnel
Additional Resources

Windows 10 Always On VPN Device Tunnel Step-by-Step Configuration using PowerShell

What’s The Difference Between DirectAccess and Always On VPN?

Windows 10 Always On VPN Recommendations for Windows Server 2016 Routing and Remote Access Service (RRAS)

Windows 10 Always On VPN Hands-On Training

DirectAccess IP-HTTPS and Symantec SSL Certificates

DirectAccess IP-HTTPS and Symantec SSL CertificatesAn SSL certificate is required to support the IP-HTTPS IPv6 transition technology when configuring DirectAccess. Implementation best practices dictate using a public SSL certificate signed by a trusted third-party vendor such as Entrust, Verisign, DigiCert, and others. SSL certificates issued by a private PKI are acceptable if the client trusts the issuing CA. Self-signed certificates are supported in some deployment scenarios, but their use is generally discouraged. For more detailed information regarding SSL certificate considerations for DirectAccess IP-HTTPS click here.

Symantec Issued Certificates

Symantec is a popular commercial SSL certificate provider that has been commonly used for many years. However, due to integrity issues associated with their PKI management practices, Google and Mozilla announced they will soon be deprecating these certificates. This means users who browse to an HTTPS web site protected with a Symantec SSL certificate will receive a warning in their browser indicating the certificate is not trusted.

DirectAccess IP-HTTPS

It is important to note that there is no impact at all for DirectAccess when the server is configured to use an SSL certificate issued by Symantec. There is nothing you need to do to address this issue in this scenario. However, if a wildcard certificate is installed on the DirectAccess server and it is also used on other public-facing web servers in the organization, it is likely that the certificate will replaced, perhaps by another certificate provider. In this case, DirectAccess IP-HTTPS must be configured to use the new or updated SSL certificate.

Updating IP-HTTPS SSL Certificate

To update the DirectAccess IP-HTTPS SSL certificate, import the SSL certificate along with the private key in to the local computer certificate store on each DirectAccess server. Next identify the thumbprint of the new SSL certificate. Finally, open an elevated PowerShell command window and enter the following command.

$thumbprint = “ssl_cert_thumbprint”
$cert = Get-ChildItem -Path cert:\localmachine\my | where {$_.thumbprint -eq $thumbprint}
Set-RemoteAccess -SslCertificate $cert -PassThru

Be sure to replace “ssl_cert_thumbprint” with the actual thumbprint of your SSL certificate. 😉 In addition, for load-balanced and/or multisite deployments, run these PowerShell commands on each server in the enterprise.

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS

DirectAccess IP-HTTPS Null Cipher Suites Not Available 

DirectAccess IP-HTTPS Performance Issues

Troubleshooting Always On VPN Errors 691 and 812

Troubleshooting Always On VPN Errors 691 and 812When configuring Windows 10 Always On VPN using the Routing and Remote Access Service (RRAS) on Windows Server 2012 R2 and Extensible Authentication Protocol (EAP) authentication using client certificates, clients attempting to establish a VPN connection using Internet Key Exchange version 2 (IKEv2) may receive the following error.

“The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile.”

Troubleshooting Always On VPN Errors 691 and 812

The event log on the client also records RasClient event ID 20227 stating “the error code returned on failure is 812”.

Troubleshooting Always On VPN Errors 691 and 812

Always On VPN clients using the Secure Socket Tunneling Protocol (SSTP) may receive the following error.

“The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.”

Troubleshooting Always On VPN Errors 691 and 812

The event log on the client also records RasClient event ID 20227 stating “the error code returned on failure is 691”.

Troubleshooting Always On VPN Errors 691 and 812

Resolution

These errors can occur when Transport Layer Security (TLS) 1.0 has been disabled on the RRAS server. To restore functionality, enable TLS 1.0 protocol support on the RRAS server. If disabling TLS 1.0 is required for compliance reasons, consider deploying RRAS on Windows Server 2016. TLS 1.0 can be safely disabled on Windows Server 2016 without breaking EAP client certificate authentication for Windows 10 Always On VPN clients.

Additional Information

Windows 10 Always On VPN Hands-On Training

What’s the Difference Between DirectAccess and Windows 10 Always On VPN?

5 Important Things DirectAccess Administrators Should Know About Windows 10 Always On VPN

3 Important Advantages of Windows 10 Always On VPN over DirectAccess 

Windows 10 Always On VPN and the Future of DirectAccess

Always On VPN Hands-On Training Classes Coming to Denver and New York

Windows 10 Always On VPN Hands-On Training Classes for 2018I’m pleased to announce that I will be bringing my popular three-day Windows 10 Always On VPN Hands-On Training classes to Denver and New York in May and June! Join me May 15-17, 2018 in Denver or June 5-7, 2018 in New York. These training classes will cover all aspects of designing, implement, and supporting an Always On VPN solution in the enterprise. These three-day courses will cover topics including…

  • Windows 10 Always On VPN overview
  • Introduction to CSP
  • Infrastructure requirements
  • Planning and design considerations
  • Installation, configuration, and client provisioning

Advanced topics will include…

  • Redundancy and high availability+
  • Cloud-based deployments
  • Third-party VPN infrastructure and client support
  • Multifactor authentication
  • Always On VPN migration strategies

Windows 10 Always On VPN Hands-On Training Classes for 2018

Register Today

Reservations are being accepted now! The cost for this 3-day hands-on training class is $4995.00 USD. Space is limited, so don’t wait to register! Fill out the form below to save your seat now.

DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

DirectAccess and Always On VPN with Trusted Platform Module (TPM) CertificatesTo enhance security when provisioning certificates for DirectAccess (computer) or Windows 10 Always On VPN (user) it is recommended that private keys be stored on a Trusted Platform Module (TPM) on the client device. A TPM is a dedicated security processor included in nearly all modern computers. It provides essential hardware protection to ensure the highest levels of integrity for digital certificates and is used to generate, store, and restrict the use of cryptographic keys. It also includes advanced security and protection features such as key isolation, non-exportability, and anti-hammering to prevent brute-force attacks.

To ensure that private keys are created and stored on a TPM, the certificate template must be configured to use the Microsoft Platform Crypto Provider. Follow the steps below to configure a certificate template required to use a TPM.

  1. Open the Certificate Templates management console (certtmpl.msc) and duplicate an existing certificate template. For example, if creating a certificate for DirectAccess, duplicate the Workstation Authentication certificate template. For Always On VPN, duplicate the User certificate template.
  2. On the Compatibility tab, ensure the Certification Authority and Certificate recipient compatibility settings are set to a minimum of Windows Server 2008 and Windows Vista/Server 2008, respectively.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates
  3. Select the Cryptography tab.
  4. Choose Key Storage Provider from the Provider Category drop down list.
  5. Choose the option Requests must use one of the following providers and select Microsoft Platform Crypto Provider.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

Note: If Microsoft Platform Crypto Provider does not appear in the list above, got to the Request Handling tab and uncheck the option Allow private key to be exported.

Complete the remaining certificate configuration tasks (template display name, subject name, security settings, etc.) and publish the certificate template. Client machines configured to use this template will now have a certificate with private key fully protected by the TPM.

Additional Resources

Trusted Platform Module (TPM) Fundamentals

DirectAccess and Always On VPN Certificate Auto Enrollment

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

What is the Difference Between DirectAccess and Always On VPN?

Always On VPN Device Tunnel Configuration Guidance Now AvailableDirectAccess has been around for many years, and with Microsoft now moving in the direction of Always On VPN, I’m often asked “What’s the difference between DirectAccess and Always On VPN?” Fundamentally they both provide seamless and transparent, always on remote access. However, Always On VPN has a number of advantages over DirectAccess in terms of security, authentication and management, performance, and supportability.

Security

DirectAccess provides full network connectivity when a client is connected remotely. It lacks any native features to control access on a granular basis. It is possible to restrict access to internal resources by placing a firewall between the DirectAccess server and the LAN, but the policy would apply to all connected clients.

Windows 10 Always On VPN includes support for granular traffic filtering. Where DirectAccess provides access to all internal resources when connected, Always On VPN allows administrators to restrict client access to internal resources in a variety of ways. In addition, traffic filter policies can be applied on a per-user or group basis. For example, users in accounting can be granted access only to their department servers. The same could be done for HR, finance, IT, and others.

Authentication and Management

DirectAccess includes support for strong user authentication with smart cards and one-time password (OTP) solutions. However, there is no provision to grant access based on device configuration or health, as that feature was removed in Windows Server 2016 and Windows 10. In addition, DirectAccess requires that clients and servers be joined to a domain, as all configuration settings are managed using Active Directory group policy.

Windows 10 Always On VPN includes support for modern authentication and management, which results in better overall security. Always On VPN clients can be joined to an Azure Active Directory and conditional access can also be enabled. Modern authentication support using Azure MFA and Windows Hello for Business is also supported. Always On VPN is managed using Mobile Device Management (MDM) solutions such as Microsoft Intune.

Performance

DirectAccess uses IPsec with IPv6, which must be encapsulated in TLS to be routed over the public IPv4 Internet. IPv6 traffic is then translated to IPv4 on the DirectAccess server. DirectAccess performance is often acceptable when clients have reliable, high quality Internet connections. However, if connection quality is fair to poor, the high protocol overhead of DirectAccess with its multiple layers of encapsulation and translation often yields poor performance.

The protocol of choice for Windows 10 Always On VPN deployments is IKEv2. It offers the best security and performance when compared to TLS-based protocols. In addition, Always On VPN does not rely exclusively on IPv6 as DirectAccess does. This reduces the many layers of encapsulation and eliminates the need for complex IPv6 transition and translation technologies, further improving performance over DirectAccess.

Supportability

DirectAccess is a Microsoft-proprietary solution that must be deployed using Windows Server and Active Directory. It also requires a Network Location Server (NLS) for clients to determine if they are inside or outside the network. NLS availability is crucial and ensuring that it is always reachable by internal clients can pose challenges, especially in very large organizations.

Windows 10 Always On VPN supporting infrastructure is much less complex than DirectAccess. There’s no requirement for a NLS, which means fewer servers to provision, manage, and monitor. In addition, Always On VPN is completely infrastructure independent and can be deployed using third-party VPN servers such as Cisco, Checkpoint, SonicWALL, Palo Alto, and more.

Summary

Windows 10 Always On VPN is the way of the future. It provides better overall security than DirectAccess, it performs better, and it is easier to manage and support.

Here’s a quick summary of some important aspects of VPN, DirectAccess, and Windows 10 Always On VPN.

Traditional VPN DirectAccess Always On VPN
Seamless and Transparent No Yes Yes
Automatic Connection Options None Always on Always on, app triggered
Protocol Support IPv4 and IPv6 IPv6 Only IPv4 and IPv6
Traffic Filtering No No Yes
Azure AD Integration No No Yes
Modern Management Yes No (group policy only) Yes (MDM)
Clients must be domain-joined? No Yes No
Requires Microsoft Infrastructure No Yes No
Supports Windows 7 Yes Yes Windows 10 only

Always On VPN Hands-On Training

If you are interested in learning more about Windows 10 Always On VPN, consider registering for one of my hands-on training classes. More details here.

Additional Resources

Always On VPN and the Future of Microsoft DirectAccess

5 Important Things DirectAccess Administrators Should Know about Windows 10 Always On VPN

3 Important Advantages of Windows 10 Always On VPN over DirectAccess

Enabling Secure Remote Administration for the NetMotion Mobility Console

During the initial setup of a NetMotion Mobility gateway server, the administrator must choose to allow either Secure (HTTPS) or Non-secure (HTTP) connections when using the web-based Mobility Console.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Configuring HTTPS

Security best practices dictate HTTPS should be enabled to protect credentials used to log on to the gateway remotely. Immediately after selecting the Secure (https:) option, the administrator is prompted to enter server certificate information. Enter this information and click OK to continue and complete the rest of the configuration as necessary.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Self-Signed Certificate

When logging in to the Mobility console, the administrator is presented with a certificate error indicating there is a problem with the website’s security certificate. This is because the certificate is self-signed by the NetMotion Mobility gateway server and is not trusted.

Enabling Secure Remote Administration for the NetMotion Mobility Console

PKI Issued Certificate

The recommended way to resolve this is to request a certificate from a trusted certification authority (CA). To do this, open the Mobility Management Tool on the Mobility gateway server and click on the Web Server tab.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click on the Server Certificate button and then click New in the Certificate Request section.

Enabling Secure Remote Administration for the NetMotion Mobility Console

In the SAN (subject alternative name) field of the Optional Extension section enter the Fully Qualified Domain Name (FQDN) of the server using the syntax dns:fqdn. Include both the FQDN and the single-label hostname (short name) separated by a comma to ensure both names work without issue. For example:

dns:nm1.lab.richardhicks.net,dns:nm1

Enabling Secure Remote Administration for the NetMotion Mobility Console

Before requesting a certificate from a CA, the root and any intermediate CA certificates must first be imported. Click the Import button next to each, as required.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Copy in the Certificate Request section to copy the Certificate Signing Request (CSR) to the clipboard and then save it to a text file. Now submit the CSR to be signed by the CA using the certreq.exe command. Open an elevated command or PowerShell window and enter the following commands.

certreq.exe -attrib “CertificateTemplate:[TemplateName]” -submit [Path_to_CSR_file]

For example:

certreq.exe -attrib “CertificateTemplate:LabWebServer” -submit certreq.txt

Select a CA from the list and click OK, then save the certificate response when prompted.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Response and specify the location of the certificate response file saved in the previous step.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Once complete, the newly issued certificate will be in place. Click Close to complete the process.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Yes when prompted to restart the Mobility console.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Trusted Certificate

Opening the Mobility Console no longer produces a certificate error message with a certificate installed from a trusted CA.

Enabling Secure Remote Administration for the NetMotion Mobility Console

In addition, if you followed the guidance above and included the single-label hostname in the SAN field, accessing the server using the short name will also work without issue.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Summary

Always select the option to use HTTPS to ensure the highest level of security and protection of credentials when remotely administering a NetMotion Mobility gateway server. For optimal security and to provide the best user experience, use a certificate issued and managed by a trusted CA to prevent certificate errors when opening the Mobility console.

Additional Information

NetMotion Mobility as an Alternative to DirectAccess

NetMotion Mobility Device Tunnel Configuration

Comparing NetMotion Mobility and DirectAccess Part 1 – Security

Comparing NetMotion Mobility and DirectAccess Part 2 – Performance

DirectAccess and NetMotion Mobility Webinar

 

%d bloggers like this: