Windows 8.1 allows a VPN client to automatically connect to the corporate network. From end user perspective, access to corporate resources works just like when he is inside the corporate network.
Whenever you launch a corporate application or access a corporate resource by name, VPN connection is automatically triggered, if it is not already connected.
Admin can configure a list of applications that will trigger the VPN connection. Whenever an application from the list is launched, VPN connection is automatically triggered.
The list of applications for which VPN connection is triggered is configured on the client as part of the VPN profile. You can add applications to the VPN profile using the Add-VpnConnectionTriggerApplication 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. You can add multiple applications at the same time. Windows supports both modern apps and traditional apps.
1. For modern apps, 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 Skype app.
You can retrieve the package full name by using the Get-appxpackage cmdlet in Powershell prompt.
2. For traditional apps, the ApplicationID is the binary path where the application is installed on the machine. Example can be “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 that if you have 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.
You can remove applications 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.
Admin can configure a set of name suffixes that will trigger the VPN connection. Whenever a resource belonging to the name suffix is accessed, VPN connection is auto triggered.
You can configure the set of name suffixes for which VPN connection is triggered 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.
You can remove name suffixes from the VPN profile by using the cmdlet Remove-VpnConnectionTriggerDnsConfiguration.
Remove-VpnConnectionTriggerDnsConfiguration [-Name] <string> –DnsSuffix <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.
There can be a case where you do not want to auto trigger your VPN connection for a particular resource since it is directly accessible over the Internet (although it is part of the corporate namespace). Say, your corporate network is contoso.com and you have a web server with URL http://internetsite.contoso.com that is directly accessible over the Internet. You provide contoso.com as the DNS suffix for which VPN connection should be triggered. Now, when you try to access the web server, VPN will get triggered unnecessarily. Resolution may also fail if your corporate DNS servers do not resolve external names. To prevent auto triggering in this case, you can add internetsite.contoso.com without any DNS server addresses as part of the name based triggering properties. The name resolution will fallback to the client’s physical interface and will go over the Internet.
When you specify an exemption, not only is the VPN connection not triggered for that name but if a VPN connection is already up, corporate names matching the exemption entry are also not resolved. Instead, such resolutions fall back to the VPN interface and if there is a DNS server configured on this interface, it is used to resolve the name.
You can also configure your VPN connection to trigger when you access a corporate resource using flat names. Lot of times, users access corporate web resources or remote desktop to their office machines using only flat names (as opposed to the full FQDN of the machine). This will work fine if your organization only has a single domain, but if there are multiple domains and resource being accessed is different from the primary DNS suffix of the machine, 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 machine as soon as the auto triggered profile is plumbed on the machine. Hence, whenever you try to access a resource by flat name, each of these suffixes are appended to the flat name one by one till name resolution succeeds over the corporate DNS server. To configure DNS suffix search list, you can use the Set-VpnConnectionTriggerDnsConfiguration cmdlet.
Set-VpnConnectionTriggerDnsConfiguration [-Name] <string> [–DnsSuffix <String>] [-DnsIPAddress <string>] [-DnsSuffixSearchList <string>] –PassThru
DnsSuffixSearchList is the parameter which stores the list of suffixes. While setting the suffix search list, the entire list should be specified including entries that are already present. The DNS suffix search list is only applicable for name based triggering. If you try to set it when only application based triggering is configured, you will get an error.
Every flat name access could potentially trigger a VPN connection because the DNS client appends a suffix to the flat name and the resulting FQDN would match a name trigger rule. When DNS tries to resolve the name after VPN comes up, the resolution could fail if it is not a valid FQDN but the VPN connection still stays connected.
A VPN connection that has been configured for name based auto triggering, will get disconnected if there is not traffic to the corporate network for a fixed period of time. You can set this time while creating a VPN connection. The relevant cmdlet is Add-VpnConnection and the parameter name is IdleDisconnectSeconds. You can also change this at any later point of time, using the cmdlet Set-VpnConnection. For auto triggered connections, the default idle timeout value is 5 minutes.
Note that if any application (configured for auto triggering in the VPN profile) is still running, 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 gets disabled. To enable auto triggering again, you have to manually check the checkbox in the Networks UI (“Let apps automatically use this VPN connection”) for the connection.
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. Some organizations may want VPN connection to be always triggered, irrespective of whether user is physically present in office or is in a remote location. If you are in that category, you don’t need to make any more changes.
Some other organizations will not want VPN connection to be triggered when users are physically inside the corporate network. To achieve this, configure trusted networks for your VPN connection. Whenever the VPN client is in a trusted network, we will not trigger the VPN connection even if user is trying to access an application/resource that matches a trigger rule.
Trusted network list is configured as a list of DNS suffixes. These DNS suffixes are matched with the connection specific DNS suffix on the physical interface of the client machine. 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. Hence, 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 user is at home or a public hotspot, the ISP will not provide a connection specific DNS suffix and VPN connection will always get triggered.
Many organizations also have a concept of guest networks, which might provide only Internet access to the user. Usually, the guest networks don’t have a connection specific DNS suffix or have a separate suffix than 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.
One more important thing to note is that we will always trigger the VPN connection if the machine’s physical interface is in a public profile. A public network cannot really be a trusted network for an organization.
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.
You can add trusted networks for VPN profile using the cmdlet Add-VpnConnectionTriggerTrustedNetwork.
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.
To remove trusted networks, use the cmdlet Remove- VpnConnectionTriggerTrustedNetwork.
Remove-VpnConnectionTriggerTrustedNetwork [-Name] <string> [-DnsSuffix] <string>
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. To revert back to default auto-population, you can use the cmdlet Set-VpnConnectionTriggerTrustedNetwork.
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. Exemption entries, identified by suffixes not having DNS servers, are not added.
Note that reverting to default will replace all the manually added suffixes with the existing DNS suffixes in the name based triggering properties.
It is possible that there are multiple auto triggered profiles on a client machine. Only one profile can be enabled for auto triggering at any point of time on a client machine. 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 that by navigating to the profile in the Networks UI. 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 are more than one profile that can be enabled for auto triggering, the first one that is provisioned on the system is selected.
If you manually disable auto triggering from a profile, none of the other profiles are enabled for auto triggering.
An auto triggered VPN profile can be seen in the Networks UI like any other VPN profile. When you click on the auto triggered profile, it expands and you can see a checkbox “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, VPN connection is triggered whenever you access a specific corporate resource or application. If your credentials are cached/known, you will get no notification and VPN connection will be automatically established. Experience will be seamless.
If credentials are not cached/ credentials have expired, you will see a system toast notification asking you to enter credentials. When you click on the toast, the Networks UI will open. When you click on the VPN connection, you will be asked to enter your credentials. Once you have entered your credentials and clicked OK, the VPN connection will try to connect.
You may have resources in your local home network that have the same name as resources in the corporate network. If auto triggering is enabled, you will not be able to access the resource in your home network, since VPN connection will be triggered every time you try to do so. To access the local network resource, you have to go to the Networks UI and disable auto triggering for the VPN connection. Once auto triggering has been disabled, you will be able to access the local resource.
If your VPN connection has already been established, disconnecting it will also disable auto triggering for the connection. To enable auto triggering again, you have to manually check the checkbox in the Networks UI (“Let apps automatically use this VPN connection”) for the connection.
For application based triggering, if an application (that is configured for triggering) is open and the machine goes to sleep, when it resumes, VPN connection will automatically trigger.
For name based triggering in the same circumstances, VPN connection will trigger when the machine resumes from sleep and you access some resource in the corporate network (that matches with the DNS suffix configured for name based triggering).
Auto triggering is not supported in a few scenarios, mentioned below:
1. Auto triggering is not supported for a VPN profile that has split tunnelling disabled.
Split tunnelling refers to the fact that only connections to the corporate network are sent over the VPN tunnels. If you want 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 NIC).
Split tunnelling can be enabled or disabled for a VPN profile (check cmdlet Add-VpnConnection or Set-VpnConnection for more details).
You can still configure auto–triggering properties even when split tunnelling has been disabled. Likewise, if auto triggering has been previously enabled, that will not prevent you from disabling split tunnelling. From functionality perspective, auto triggering capability will not be available for split tunnelling disabled profiles.
2. Auto triggering is not supported on domain joined machines
Auto triggering of VPN connections will not work on domain joined machines. Since you may want to export profiles to other computers, you can configure auto triggering properties on domain joined machines through PowerShell. But it will not work on the domain joined machines.
Log collection for VPN is very simple in Windows 8.1. You do not have to repro issues anymore and you can easily get logs even for issues that occur very inconsistently.
Whenever you dial a VPN connection, logging is automatically started. Logging is stopped when the VPN connection is disconnected. When another VPN connection is dialled later, the old logs are overwritten. If multiple VPN connections are connected, logging will be stopped once all the connections have been disconnected.
To explicitly enable logging, you can use the following command:
Netsh ras set tr * en
To explicitly disable logging, you can use the following command:
Netsh ras set tr * dis
Apart from RAS tracing logs, you can collect additional system logs by using the following command:
Netsh ras diagnostics show all type= file destination= c:\temp\logs
The log is generated as a HTML file. It contains the following information:
Note that if you have manually enabled logging, you will need to explicitly disable logging. Disconnecting the VPN connection will not disable logging.
We have introduced events for auto triggering configuration and state changes. These are useful for debugging and can be found in the following event channels, Windows Networking Vpn Plugin Platform/Operational and Microsoft-Windows-VPN/Operational.
Some of the events are given below:
VPN profile creation
VPN Profile VpnSelfhost has been created with the following properties: ServerAddress: edge.microsoft.com RememberCredential: false SplitTunneling: true DnsSuffix: corp.microsoft.com VpnServerList: null IdleDisconnectSeconds: 0 AllUserConnection: false EncryptionLevel: Required TunnelType: Sstp EapConfiguration: true UseWinlogonCredential: false L2tpPsk: false AuthenticationMethod: Eap MachineCertificateEKUFilter: null
VPN profile update
VPN Connection VpnSelfhost has been modified with the following properties: Add Route: DestinationPrefix: 18.104.22.168/27
Auto trigger profile added
Autotrigger: [VpnSelfhost], profile added
Auto trigger profile activated
Autotrigger: [VpnSelfhost], profile got activated
Trusted network determination
Autotrigger [VpnSelfhost], device is inside the trusted network boundary [corp.microsoft.com]
Auto trigger connection in progress
Autotrigger: [VpnSelfhost], device is attempting to connect to VPN. Please refer to Microsoft-Windows-VPN channel under WFP for cause of connect
Resource triggering VPN connection
Autotrigger: DNS query corp.microsoft.com is made, matching VPN trigger rules
Auto trigger connect successful
Autotrigger: [VpnSelfhost], device is connected to VPN
System Center 2012 R2 Configuration Manager and Windows Intune now supports configuring profiles for VPN on Windows 8.1 devices. They also support configuring auto triggering properties for VPN connections. They also provide the functionality to upload VPN configuration XML profiles (Windows 8 RT and Windows 8.1 devices). More information about configuring VPN profiles in Windows 8.1 can be found at http://blogs.technet.com/b/configmgrteam/archive/2013/07/10/compliance-settings-and-company-resource-access.aspx.
System Center 2012 R2 Configuration Manager and the Windows Intune service also provides the capability of associating a VPN profile to an application when the application is deployed through Configuration Manager. When the application is installed on the device by the end user, Configuration Manager also automatically associates it to the VPN profile. Whenever user launches the application, VPN connection will be automatically triggered. More details can be found in the blog post http://blogs.technet.com/b/configmgrteam/archive/2013/07/10/user-centric-application-management.aspx
I managed to configure a working name based trigger, unfortunately with an annoying issue.
Whenever I ping or browse my intranet server (for example: intranet.contoso.com) the VPN connection is established. Whenever I try to access my mapped network drive (for example: \\fileserver or \\fileserver.contoso.com) the connection isn't established.
When I do some troubleshooting with Network Monitor 3.4, I can see that in both situations (ping or browse intranet and connect mapped network drive) my computer is performing a DNS query towards my internal DNS servers. However only ping requests and browse requests towards my intranet server records Event ID 2029 (Autotrigger: DNS query intranet.contoso.com is made, matching VPN trigger rules) in VPN Plugin Platform event log. I thought to be smart and added "FileManager_cw5n1h2txyewy" as an application trigger, but this didn't work to. Problably because it's active all the time.
Conclusion: Triggered VPN isn't a solution for automatically connecting to mapped network drives on the go.
and you think ms will look into this and answer?