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 a 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.
A VPN connection that has been configured for auto triggering, will get disconnected if all the applications that are part of VPN Connection triggering properties are closed.
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, 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 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.
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>
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.
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.
Auto triggering is not supported in a few scenarios, mentioned below:
1. Auto triggering is not supported for a VPN profile that has split tunneling disabled.
Split tunneling 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 tunneling 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 tunneling has been disabled. Likewise, if auto triggering has been previously enabled, that will not prevent you from disabling split tunneling. From functionality perspective, auto triggering capability will not be available for split tunneling 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 dialed 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: 220.127.116.11/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
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?
Here's another scenario that doesn't work for Win8.1, and illustrates the need to allow PROGRAMMATIC invocation of VPN connections. SCENARIO: President of Company has 3 locations, each with location-specific VPN access. PROBLEM 1: Even if Remote Desktop
(mstsc.exe) is associated with one of the VPNs, it takes longer to complete the connection than mstsc is willing to wait, and it gives an error; however the VPN connection is made and you can ping onto the local network (while the mstsc error message is still
up). PROBLEM 2: Sometimes the president and his laptop are on-site and the VPN is not needed or desired. SOLUTION: Need to be able to programmatically start up VPN connection, as was possible in earlier versions of Windows. ALGORITHM: 1. Test for access to
desired destination; if present no VPN needed (i.e., president is on-site). 2. Depending on which RDP target is chosen, start up the appropriate VPN, wait until connection established (ping or other test), then invoke mstsc.exe with desired target. 3. After
mstsc.exe exists, take down appropriate VPN.