Configure Windows Server 2012 R2 VPN Auto trigger

[Content in this topic that applies specifically to Windows Server 2012 R2 Preview is preliminary and subject to change in future releases.]

This document describes how to configure VPN auto trigger in Windows 8.1. Windows 8.1 allows a VPN client to automatically connect to a corporate network when a corporate application is launched, or a corporate resource is accessed by name.

In this Document

The configuration options covered in this document include:

  • Application-based triggering

  • Name-based triggering

  • Trusted networks for auto triggered VPN connections

  • Multiple auto triggered profiles

  • User experience

  • Local resource access

  • Split tunneling

  • Auto triggering on domain joined computers

  • Sleep/resume

Application-based triggering

Applications can be added to the VPN profile using the Add-VpnConnectionTriggerApplication PowerShell cmdlet.

Add-VpnConnectionTriggerApplication [-Name] <string>  –ApplicationID <String[]> -PassThru

Here, Name is the name of the VPN profile and ApplicationID is the identifier for an application. Multiple applications can be added at the same time. Windows supports the following two types of applications:

  • Modern

  • Traditional (x86/x64)

Modern Applications

For modern applications, the ApplicationID is the package family name of the modern app. Examples are Microsoft.BingNews_8wekyb3d8bbwe, for the Bing News app and Microsoft.SkypeApp_kzf8qxf38zg5c for the Skype app.

The package full name can be retrieved by using the Get-appxpackage cmdlet in Powershell prompt as in the following example:

Traditional Applications

For traditional apps, the ApplicationID is the binary path where the application is installed on the computer, such as, C:\Windows\System32\notepad.exe. You can also use environmental variables in the path. For example: $env:SystemDrive\Program Files (x86)\WTT Atlas\Studio\wttstudio.exe.

Note

If the user has not installed the application in the same binary path as specified in the profile, VPN connection will not get triggered when the application is launched.

Removing application-based triggering

Applications can be removed from the VPN profile by using the cmdlet Remove-VpnConnectionTriggerApplication.

Remove-VpnConnectionTriggerApplication [-Name] <string>  –ApplicationID <String[]>  -PassThru

Here, Name is the name of the VPN profile and ApplicationID is the identifier for an application. Multiple applications can be removed at the same time.

Disconnection of application-based auto triggered VPN profiles

A VPN connection that has been configured for application based auto triggering, will disconnect if there is not traffic to the corporate network for a fixed period of time. This time can be set while creating a VPN connection using the Add-VpnConnection cmlet with parameter IdleDisconnectSeconds. The time specification can also be changed at any later time using Set-VpnConnection. For auto triggered connections, the default idle timeout value is 5 minutes.

Note

If any application (configured for auto triggering in the VPN profile) is still open, the VPN connection will not be disconnected even if there is no traffic to the corporate network for time greater than IdleDisconnectSeconds.

If you manually disconnect an auto triggered VPN profile, the auto triggering capability will be disabled. To enable auto triggering again, manually check Let apps automatically use this VPN connection for the connection.

Name-based triggering

In addition to application-based triggering, you can also configure auto triggering to use a set of name suffixes that will trigger the VPN connection. Whenever a resource belonging to the name suffix is accessed, the VPN connection is auto triggered.

The set of name suffixes for which a VPN connection is triggered is configured on the client as part of the VPN profile. Name suffixes can be added to the VPN profile using the Add-VpnConnectionTriggerDnsConfiguration cmdlet.

Add-VpnConnectionTriggerDnsConfiguration [-Name] <string>  –DnsSuffix <String> [-DnsIPAddress <string[]>] –PassThru

Here, Name is the name of the VPN profile and DnsSuffix is the suffix for which VPN connection has to be triggered.

For every DNS suffix, you must also provide DNS servers. For all name resolutions of a resource that matches the DNS suffix, the corresponding DNS servers are used. You can provide one or multiple DNS servers for each DNS suffix.

Removing name-based triggering

Name suffixes can be removed from the VPN profile by using the cmdlet Remove-VpnConnectionTriggerDNSConfiguration.

Remove-VpnConnectionTriggerDnsConfiguration [-Name] <string>  –DnsSuffix <String> [-DnsIPAddress <string[]>] –PassThru

Here, Name is the name of the VPN profile and DnsSuffix is the DNS suffix that has to be removed. Multiple DNS suffixes can be removed at the same time.

Specifying exemptions

There may be cases when you do not want to auto-trigger your VPN connection for a particular resource. You might want a certain resource to be accessed through the Internet, even though it is part of the corporate namespace. To accomplish this, omit the DNS server addresses from the DNS triggering properties so that the name resolution will fall back to the client’s physical interface and will go over the Internet.

For example, if your corporate network is contoso.com and you have a web server with URL https://internetsite.contoso.com that is directly accessible over the Internet, if you specify DNS server addresses, VPN will get triggered and the client will try to resolve the URL, which may fail if your corporate DNS servers do not resolve external names.

Note

You can specify an exemption for a resource that will perform name resolution, but not trigger your VPN connection, even if you have specified a DNS server. Name resolution will fall back to the DNS server specified in the VPN interface settings.

Short name access

You can also configure your VPN connection to trigger when the client accesses a corporate resource using flat names. Users often access corporate web resources, or remote in to their desktop office computers using only flat names (as opposed to the full FQDN of the computer). This will work fine if your organization only has a single domain, but if there are multiple domains and the resource being accessed is different from the primary DNS suffix of the computer, flat name access will not work.

To solve this issue, you can configure a DNS suffix search list as part of your VPN profile. These suffixes are added in the DNS suffix search list of your computer as soon as the auto triggered profile is plumbed on the computer. Hence, whenever user tries to access a resource by flat name, each of these suffixes are appended to the flat name one by one, until name resolution succeeds over the corporate DNS server. To configure DNS suffix search lists, you can use the Set-VpnConnectionTriggerDnsConfiguration cmdlet.

Set-VpnConnectionTriggerDnsConfiguration [-Name] <string>  [–DnsSuffix <String>] [-DnsIPAddress <string[]>] [-DnsSuffixSearchList <string[]>] –PassThru

DnsSuffixSearchList is the parameter that stores the list of suffixes. Every time you set this parameter, the entire list is replaced. So, you need to ensure that you provide the entire DNS suffix search list whenever you set this parameter. Note that DnsSuffixSearchList can only be configured when name based triggering is configured.

Important

When a client tries to access a resource using a short name (even if it is not a corporate network resource), the VPN connection will always get triggered.

For example, if your corporate network is contoso.com, and there is a resource named “xyz” which resides in corp.contoso.com, he FQDN of the resource is xyz.corp.contoso.com. Although the correct FQDN is formed by appending the suffix (corp.contoso.com), the name of the resource cannot be resolved since the VPN connection has not yet been triggered.

Any application (configured for auto triggering in the VPN profile) that is still open will not be disconnected, even if there is no traffic to the corporate network for a time greater than IdleDisconnectSeconds.

Disconnection of name-based auto triggered VPN profiles

A VPN connection that has been configured for name based auto triggering, will disconnect if there is not traffic to the corporate network for a fixed period of time. This time can be set while creating a VPN connection using the Add-VpnConnection cmdlet with parameter IdleDisconnectSeconds. The time specification can also be changed at any later time using Set-VpnConnection. For auto triggered connections, the default idle timeout value is 5 minutes.

Trusted networks for auto triggered VPN connections

Once you have configured your VPN profile with auto triggering rules (apps/namespaces/both), you need to determine when the VPN connection should be triggered. You may want VPN connections to always be triggered, regardless of whether the client computer is physically present in the office or is in a remote location.

However, you may not want a VPN connection to be triggered when users are physically inside the corporate network. To achieve this, you should configure trusted networks for your VPN connection. Whenever a user is in a trusted network, the VPN will not trigger even if the user is trying to access an application/resource that is part of the VPN triggering properties. This is achieved by matching the trusted network list with the connection specific DNS suffix on the physical interface of the client computer. If the connection specific DNS suffix is part of the list of suffixes specified in the trusted network list, the VPN connection will not be triggered. Note that each suffix configured in the trusted network list acts as a wildcard. So, if you have specified contoso.com as the trusted network, and you have any suffix in *.contoso.com as your connection specific DNS suffix, then your VPN connection will not get triggered. Normally, when the client computer is on the Internet, the physical interface will not have a connection specific DNS suffix and VPN connections will always be triggered.

Many organizations also use guest networks. Depending on your organization policies, you might want to provide guest network client computers access to the corporate network, or restrict them to the Internet. Usually, guest networks don’t have a connection specific DNS suffix, or they have a different suffix from the rest of the corporate network. You can configure your profile to have your guest network suffix as part of the trusted network list, or to be outside the list.

Important

A public network is inherently insecure, so a VPN connection will always trigger if the computer’s physical interface is in a public profile.

Configuring a trusted network

Trusted networks for VPN profiles can be configured using the Add-VpnConnectionTriggerTrustedNetwork cmdlet.

Add-VpnConnectionTriggerTrustedNetwork [-Name] <string> [-DnsSuffix] <string[]>

Here, Name is the name of the VPN profile and DnsSuffix is the trusted network that you want to add to the profile.

You can also choose to reuse the DNS suffixes that you have provided for name based triggering (using Add-VpnConnectionTriggerDnsConfiguration) for the trusted network list. This can be done using the Set-VpnConnectionTriggerTrustedNetwork cmdlet.

Set-VpnConnectionTriggerTrustedNetwork [-Name] <string> [-DefaultDnsSuffixes] 

Here, Name is the name of the VPN profile and DefaultDnsSuffixes is a mandatory switch parameter. Once this is set, all suffixes that are added/removed from name-based triggering will automatically be updated in the trusted network list. Note that suffixes without corresponding DNS server addresses will not be copied. Also, leading dots, if any, will be removed when copying to the trusted network list.

If you are using the default auto-population for trusted networks and then you subsequently add/remove trusted networks from the trusted network list, the auto-population will cease to continue. Also, if you are manually adding and removing trusted networks from the trusted network list and then you run the Set-VpnConnectionTriggerTrustedNetwork cmdlet to revert to default auto-population, all the existing trusted networks will be replaced with the existing DNS suffixes in the DNS triggering properties.

Note

When you configure name-based triggering, by default, it starts adding DNS suffixes to the trusted network list. If you do not want this auto-population, you need to remove the trusted networks already added through the auto-population. Once you manually remove a trusted network, the auto-population will cease to continue.

Multiple auto triggered profiles

It is possible to have multiple auto triggered profiles on a client computer. Consider the following situation: A user might be an employee of a particular company and a vendor for another company. Both of these companies could be installing auto triggered VPN profiles onto their user’s computer.

Only one profile can be enabled for auto triggering at any point of time on a client computer. If there are multiple profiles, the first profile provisioned on the system will have auto triggering enabled and all subsequent auto trigger capable profiles will have auto triggering disabled. If you want to enable auto triggering for any other profile, you can do so by navigating to the profile in Networks, as shown in the figure below. Once you enable auto triggering for another profile, the original auto trigger enabled profile will be disabled for auto triggering.

If for some reason the auto trigger enabled profile gets deleted from the system, the next available auto trigger capable profile is enabled for auto triggering. If there is more than one profile that can be enabled for auto triggering, the first one that is provisioned on the system is selected.

If auto triggering is manually disabled from a profile, none of the other profiles are enabled for auto triggering.

User experience

An auto triggered VPN profile can be seen in the Networks like any other VPN profile. When you click on the auto triggered profile, it expands to show a checkbox labeled Let apps automatically use the VPN connection. If this checkbox is checked, auto triggering is enabled for the profile. If this checkbox is unchecked, auto triggering is disabled.

If auto triggering is enabled for a profile, the VPN connection is triggered whenever the user accesses a specific corporate resource or application. If the user credentials are cached/known, the user will get no notification and the VPN connection will be automatically established. If credentials are not cached or the credentials have expired, the user will be asked to provide them

Local resource access

If resources on the local home network have the same name as resources in the corporate network. The home network resources will be inaccessible while the VPN is connected. To access the local network resource, auto triggering must be disabled in Networks Once auto triggering has been disabled, local resources will be available.

If the VPN connection has already been established, disconnecting it will also disable auto triggering for the connection. To enable auto triggering again, manually check Let apps automatically use this VPN connection in Networks for the connection.

Split tunneling

Split tunneling refers to the fact that only connections to the corporate network are sent over the VPN tunnels. If the user wants to connect to resources on the Internet, the connection is made over the local link (that is to say, the connection is sent directly to the Internet based on the IP addressing configuration on the client computer’s network interface card

Split tunneling can be enabled or disabled for a VPN profile using the cmdlets Add-VpnConnection and Set-VpnConnection, respectively. Auto triggering will not work with a VPN profile that has split tunneling disabled.

Note

You can still configure auto–triggering properties even when split tunneling has been disabled. Likewise, if auto triggering has been previously enabled, that will not prevent you from disabling split tunneling.

Auto triggering on domain joined computers

Auto triggering of VPN connections will not work on domain joined computers. Since you may want to export profiles to other computers, you can configure auto triggering properties on domain joined computers through PowerShell. But auto triggering will not work in a VPN profile if the client computer is domain joined.

Sleep/resume

For application based triggering, if an application (that is configured for triggering) is open and the computer goes to sleep, when it resumes, the VPN connection will automatically trigger.

For name-based triggering in the same circumstances, the VPN connection will trigger when the computer resumes from sleep and the user accesses some resource in the corporate network (that matches with the DNS suffix configured for name based triggering).