resolved conflicts

This commit is contained in:
Paolo Matarazzo
2023-05-24 16:42:58 -04:00
187 changed files with 1918 additions and 892 deletions

View File

@ -0,0 +1,36 @@
---
title: How to configure Diffie Hellman protocol over IKEv2 VPN connections
description: Learn how to update the Diffie Hellman configuration of VPN servers and clients by running VPN cmdlets to secure connections.
ms.date: 09/23/2021
ms.topic: how-to
---
# How to configure Diffie Hellman protocol over IKEv2 VPN connections
In IKEv2 VPN connections, the default configuration for Diffie Hellman group is Group 2, which is not secure for IKE exchanges.
To secure the connections, update the configuration of VPN servers and clients by running VPN cmdlets.
## VPN server
For VPN servers that run Windows Server 2012 R2 or later, you need to run [Set-VpnServerConfiguration](/powershell/module/remoteaccess/set-vpnserverconfiguration?view=win10-ps&preserve-view=true) to configure the tunnel type. This makes all IKE exchanges on IKEv2 tunnel use the secure configuration.
```powershell
Set-VpnServerConfiguration -TunnelType IKEv2 -CustomPolicy
```
On an earlier version of Windows Server, run [Set-VpnServerIPsecConfiguration](/previous-versions/windows/powershell-scripting/hh918373(v=wps.620)). Since `Set-VpnServerIPsecConfiguration` doesn't have `-TunnelType`, the configuration applies to all tunnel types on the server.
```powershell
Set-VpnServerIPsecConfiguration -CustomPolicy
```
## VPN client
For VPN client, you need to configure each VPN connection.
For example, run [Set-VpnConnectionIPsecConfiguration (version 4.0)](/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps&preserve-view=true) and specify the name of the connection:
```powershell
Set-VpnConnectionIPsecConfiguration -ConnectionName <String>
```

View File

@ -0,0 +1,94 @@
---
title: How to use Single Sign-On (SSO) over VPN and Wi-Fi connections
description: Explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections.
ms.date: 12/28/2022
ms.topic: how-to
---
# How to use Single Sign-On (SSO) over VPN and Wi-Fi connections
This article explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections. The following scenarios are typically used:
- Connecting to a network using Wi-Fi or VPN
- Use credentials for Wi-Fi or VPN authentication to also authenticate requests to access domain resources, without being prompted for domain credentials
For example, you want to connect to a corporate network and access an internal website that requires Windows integrated authentication.
The credentials that are used for the connection authentication are placed in *Credential Manager* as the default credentials for the **logon session**. Credential Manager stores credentials that can be used for specific domain resources. These are based on the target name of the resource:
- For VPN, the VPN stack saves its credential as the **session default**
- For WiFi, Extensible Authentication Protocol (EAP) provides support
The credentials are placed in Credential Manager as a *session credential*:
- A *session credential* implies that it is valid for the current user session
- The credentials are cleaned up when the WiFi or VPN connection is disconnected
> [!NOTE]
> In Windows 10, version 21H2 and later, the *session credential* is not visible in Credential Manager.
For example, if someone using Microsoft Edge tries to access a domain resource, Microsoft Edge has the right Enterprise Authentication capability. This allows [WinInet](/windows/win32/wininet/wininet-reference) to release the credentials that it gets from Credential Manager to the SSP that is requesting it.
For more information about the Enterprise Authentication capability, see [App capability declarations](/windows/uwp/packaging/app-capability-declarations).
The local security authority will look at the device application to determine if it has the right capability. This includes items such as a Universal Windows Platform (UWP) application.
If the app isn't a UWP, it doesn't matter.
But, if the application is a UWP app, it will evaluate at the device capability for Enterprise Authentication.
If it does have that capability and if the resource that you're trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential will be released.
This behavior helps prevent credentials from being misused by untrusted third parties.
## Intranet zone
For the Intranet zone, by default it only allows single-label names, such as *http://finance*.
If the resource that needs to be accessed has multiple domain labels, then the workaround is to use the [Registry CSP](/windows/client-management/mdm/registry-csp).
### Setting the ZoneMap
The ZoneMap is controlled using a registry that can be set through MDM.
By default, single-label names such as *http://finance* are already in the intranet zone.
For multi-label names, such as *http://finance.net*, the ZoneMap needs to be updated.
## MDM Policy
OMA URI example:
`./Vendor/MSFT/Registry/HKU/S-1-5-21-2702878673-795188819-444038987-2781/Software/Microsoft/Windows/CurrentVersion/Internet%20Settings/ZoneMap/Domains/<domain name>` as an `Integer` value of `1` for each of the domains that you want to SSO into from your device. This adds the specified domains to the Intranet Zone of the Microsoft Edge browser.
## Credential requirements
For VPN, the following types of credentials will be added to credential manager after authentication:
- Username and password
- Certificate-based authentication:
- TPM Key Storage Provider (KSP) Certificate
- Software Key Storage Provider (KSP) Certificates
- Smart Card Certificate
- Windows Hello for Business Certificate
The username should also include a domain that can be reached over the connection (VPN or WiFi).
## User certificate templates
If the credentials are certificate-based, then the elements in the following table need to be configured for the certificate templates to ensure they can also be used for Kerberos client authentication.
| Template element | Configuration |
|------------------|---------------|
| SubjectName | The user's distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
| SubjectAlternativeName | The user's fully qualified UPN where a domain name component of the user's UPN matches the organizations internal domain's DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
| Key Storage Provider (KSP) | If the device is joined to Azure AD, a discrete SSO certificate is used. |
| EnhancedKeyUsage | One or more of the following EKUs is required: </br><ul><li>Client Authentication (for the VPN)</li><li>EAP Filtering OID (for Windows Hello for Business)</li><li>SmartCardLogon (for Azure AD-joined devices)</li></ul>If the domain controllers require smart card EKU either:<ul><li>SmartCardLogon</li><li>id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) </li></ul>Otherwise:</br><ul><li>TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)</li></ul> |
## NDES server configuration
The NDES server is required to be configured so that incoming SCEP requests can be mapped to the correct template to be used.
For more information, see [Configure certificate infrastructure for SCEP](/mem/intune/protect/certificates-scep-configure).
## Active Directory requirements
You need IP connectivity to a DNS server and domain controller over the network interface so that authentication can succeed as well.
Domain controllers must have appropriate KDC certificates for the client to trust them as domain controllers. Because phones are not domain-joined, the root CA of the KDC's certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store.
Domain controllers must be using certificates based on the updated KDC certificate template Kerberos Authentication.
This requires that all authenticating domain controllers run Windows Server 2016, or you'll need to enable strict KDC validation on domain controllers that run previous versions of Windows Server.
For more information, see [Enabling Strict KDC Validation in Windows Kerberos](https://www.microsoft.com/download/details.aspx?id=6382).

Binary file not shown.

After

Width:  |  Height:  |  Size: 228 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 176 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 94 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 82 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 200 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 254 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 168 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 315 KiB

View File

@ -0,0 +1,25 @@
items:
- name: Overview
href: vpn-guide.md
- name: VPN connection types
href: vpn-connection-type.md
- name: VPN routing decisions
href: vpn-routing.md
- name: VPN authentication options
href: vpn-authentication.md
- name: VPN and conditional access
href: vpn-conditional-access.md
- name: VPN name resolution
href: vpn-name-resolution.md
- name: VPN auto-triggered profile options
href: vpn-auto-trigger-profile.md
- name: VPN security features
href: vpn-security-features.md
- name: VPN profile options
href: vpn-profile-options.md
- name: How to configure Diffie Hellman protocol over IKEv2 VPN connections
href: how-to-configure-diffie-hellman-protocol-over-ikev2-vpn-connections.md
- name: How to use single sign-on (SSO) over VPN and Wi-Fi connections
href: how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
- name: Optimizing Office 365 traffic with the Windows VPN client
href: vpn-office-365-optimization.md

View File

@ -0,0 +1,92 @@
---
title: VPN authentication options
description: Learn about the EAP authentication methods that Windows supports in VPNs to provide secure authentication using username/password and certificate-based methods.
ms.date: 09/23/2021
ms.topic: conceptual
---
# VPN authentication options
In addition to older and less-secure password-based authentication methods (which should be avoided), the built-in VPN solution uses Extensible Authentication Protocol (EAP) to provide secure authentication using both user name and password, and certificate-based methods. You can only configure EAP-based authentication if you select a built-in VPN type (IKEv2, L2TP, PPTP or Automatic).
Windows supports a number of EAP authentication methods.
- EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (EAP-MSCHAPv2):
- User name and password authentication
- Winlogon credentials - can specify authentication with computer sign-in credentials
- EAP-Transport Layer Security (EAP-TLS):
- Supports the following types of certificate authentication:
- Certificate with keys in the software Key Storage Provider (KSP)
- Certificate with keys in Trusted Platform Module (TPM) KSP
- Smart card certificates
- Windows Hello for Business certificate
- Certificate filtering:
- Certificate filtering can be enabled to search for a particular certificate to use to authenticate with
- Filtering can be Issuer-based or extended key usage (EKU)-based
- Server validation - with TLS, server validation can be toggled on or off:
- Server name - specify the server to validate
- Server certificate - trusted root certificate to validate the server
- Notification - specify if the user should get a notification asking whether to trust the server or not
- [Protected Extensible Authentication Protocol (PEAP)](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754179(v=ws.11)):
- Server validation - with PEAP, server validation can be toggled on or off:
- Server name - specify the server to validate
- Server certificate - trusted root certificate to validate the server
- Notification - specify if the user should get a notification asking whether to trust the server or not
- Inner method - the outer method creates a secure tunnel inside while the inner method is used to complete the authentication:
- EAP-MSCHAPv2
- EAP-TLS
- Fast Reconnect: reduces the delay between an authentication request by a client and the response by the Network Policy Server (NPS) or other Remote Authentication Dial-in User Service (RADIUS) server. This reduces resource requirements for both client and server, and minimizes the number of times that users are prompted for credentials.
- [Cryptobinding](/openspecs/windows_protocols/ms-peap/757a16c7-0826-4ba9-bb71-8c3f1339e937): By deriving and exchanging values from the PEAP phase 1 key material (**Tunnel Key**) and from the PEAP phase 2 inner EAP method key material (**Inner Session Key**), it is possible to prove that the two authentications terminate at the same two entities (PEAP peer and PEAP server). This process, termed "cryptobinding", is used to protect the PEAP negotiation against "Man in the Middle" attacks.
- Tunneled Transport Layer Security (TTLS)
- Inner method
- Non-EAP
- Password Authentication Protocol (PAP)
- CHAP
- MSCHAP
- MSCHAPv2
- EAP
- MSCHAPv2
- TLS
- Server validation: in TTLS, the server must be validated. The following can be configured:
- Server name
- Trusted root certificate for server certificate
- Whether there should be a server validation notification
For a UWP VPN plug-in, the app vendor controls the authentication method to be used. The following credential types can be used:
- Smart card
- Certificate
- Windows Hello for Business
- User name and password
- One-time password
- Custom credential type
## Configure authentication
See [EAP configuration](/windows/client-management/mdm/eap-configuration) for EAP XML configuration.
>[!NOTE]
>To configure Windows Hello for Business authentication, follow the steps in [EAP configuration](/windows/client-management/mdm/eap-configuration) to create a smart card certificate. [Learn more about Windows Hello for Business.](../../../identity-protection/hello-for-business/hello-identity-verification.md).
The following image shows the field for EAP XML in a Microsoft Intune VPN profile. The EAP XML field only appears when you select a built-in connection type (automatic, IKEv2, L2TP, PPTP).
:::image type="content" source="images/vpn-eap-xml.png" alt-text="EAP XML configuration in Intune profile.":::
## Related topics
- [VPN technical guide](vpn-guide.md)
- [VPN connection types](vpn-connection-type.md)
- [VPN routing decisions](vpn-routing.md)
- [VPN and conditional access](vpn-conditional-access.md)
- [VPN name resolution](vpn-name-resolution.md)
- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
- [VPN security features](vpn-security-features.md)
- [VPN profile options](vpn-profile-options.md)

View File

@ -0,0 +1,90 @@
---
title: VPN auto-triggered profile options
description: With auto-triggered VPN profile options, Windows can automatically establish a VPN connection based on IT admin-defined rules. Learn about the types of auto-trigger rules that you can create for VPN connections.
ms.date: 05/24/2023
ms.topic: conceptual
---
# VPN auto-triggered profile options
Windows can use different features to auto-trigger VPN, avoiding users to manually connect when VPN is needed to access necessary resources. There are three different types of auto-trigger rules:
- Application trigger
- Name-based trigger
- Always On
> [!NOTE]
> Auto-triggered VPN connections won't work if **Folder Redirection** for **AppData** is enabled. Either Folder Redirection for AppData must be disabled, or the auto-triggered VPN profile must be deployed in SYSTEM context, which changes the path to where the *rasphone.pbk* file is stored.
## Application trigger
VPN profiles can be configured to automatically connect on the execution of certain applications:
- You can configure desktop or Universal Windows Platform (UWP) apps to trigger a VPN connection
- You can configure per-app VPN and specify traffic rules for each app
> [!NOTE]
> The app identifier for a desktop app is a file path. The app identifier for a UWP app is a package family name.
>
> [Find a package family name (PFN) for per-app VPN configuration](/mem/configmgr/protect/deploy-use/find-a-pfn-for-per-app-vpn)
For more information, see [Traffic filters](vpn-security-features.md#traffic-filters).
## Name-based trigger
You can configure a domain name-based rule so that a specific domain name triggers the VPN connection.\
Name-based auto-trigger can be configured using the `VPNv2/<ProfileName>/DomainNameInformationList/dniRowId/AutoTrigger` setting in the [VPNv2 Configuration Service Provider (CSP)](/windows/client-management/mdm/vpnv2-csp).
There are four types of name-based triggers:
- Short name: for example, if *HRweb* is configured as a trigger, and the stack sees a DNS resolution request for *HRweb*, the VPN triggers
- Fully qualified domain name (FQDN): for example, if *HRweb.corp.contoso.com* is configured as a trigger, and the stack sees a DNS resolution request for *HRweb.corp.contoso.com*, the VPN triggers
- Suffix: for example, if *.corp.contoso.com* is configured as a trigger, and the stack sees a DNS resolution request with a matching suffix (such as *HRweb.corp.contoso.com*), the VPN triggers. For any short name resolution, VPN triggers, and the DNS servers are queried for the *<ShortName\>.corp.contoso.com*
- All: if used, all DNS resolution triggers VPN
## Always On
Always On is a Windows feature that enables the active VPN profile to connect automatically on the following triggers:
- User sign-in
- Network change
- Device screen on
When the trigger occurs, VPN tries to connect. If an error occurs, or any user input is needed, the user sees a toast notification for more interaction.
When a device has multiple profiles with Always On triggers, the user can specify the active profile in **Settings > Network & Internet > VPN > <VPN profile\>** by selecting the **Let apps automatically use this VPN connection** checkbox. By default, the first MDM-configured profile is marked as **Active**. Devices with multiple users have the same restriction: only one profile, and therefore only one user, is able to use the Always On triggers.
## Preserving user Always On preference
Another Windows feature is to preserve a user's Always On preference. If a user manually unchecks the **Connect automatically** checkbox, Windows remembers the user preference for the profile name by adding the profile name to the registry value *AutoTriggerDisabledProfilesList*.
If a management tool removes or adds the same profile name back and set **AlwaysOn** to **true**, Windows doesn't check the box if the profile name exists in the following registry value, in order to preserve user preference.
**Key:** `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Config`\
**Value:** `AutoTriggerDisabledProfilesList`\
**Type:** `REG_MULTI_SZ`
## Trusted network detection
The **Trusted network detection** feature configures the VPN so that connection isn't triggered when a device is on a trusted network. To configure Trusted network detection, you must provide a list of DNS suffixes. The VPN stack verifies the network name of the physical interface connection profile: if it matches any of the suffixes configured in the list and the network is private or provisioned by MDM, then VPN doesn't trigger.
Trusted network detection can be configured using the `VPNv2/<ProfileName>/TrustedNetworkDetection` setting in the [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp).
## Configure app-triggered VPN
See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
The following image shows associating apps to a VPN connection in a VPN Profile configuration policy using Microsoft Intune.
:::image type="content" source="images/vpn-app-trigger.png" alt-text="Creation of VPN profile in Intune: application association options." lightbox="images/vpn-app-trigger.png":::
## Related articles
- [VPN technical guide](vpn-guide.md)
- [VPN connection types](vpn-connection-type.md)
- [VPN routing decisions](vpn-routing.md)
- [VPN authentication options](vpn-authentication.md)
- [VPN and conditional access](vpn-conditional-access.md)
- [VPN name resolution](vpn-name-resolution.md)
- [VPN security features](vpn-security-features.md)
- [VPN profile options](vpn-profile-options.md)

View File

@ -0,0 +1,102 @@
---
title: VPN and conditional access
description: Learn how to integrate the VPN client with the Conditional Access platform, and how to create access rules for Azure Active Directory (Azure AD) connected apps.
ms.date: 05/23/2023
ms.topic: conceptual
---
# VPN and conditional access
The VPN client is now able to integrate with the cloud-based Conditional Access Platform to provide a device compliance option for remote clients. Conditional Access is a policy-based evaluation engine that lets you create access rules for any Azure Active Directory (Azure AD) connected application.
>[!NOTE]
>Conditional Access is an Azure AD Premium feature.
Conditional Access Platform components used for Device Compliance include the following cloud-based services:
- [Conditional Access Framework](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn)
- [Azure AD Connect Health](/azure/active-directory/connect-health/active-directory-aadconnect-health)
- [Windows Health Attestation Service](../../../threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md#device-health-attestation) (optional)
- Azure AD Certificate Authority - It is a requirement that the client certificate used for the cloud-based device compliance solution be issued by an Azure Active Directory-based Certificate Authority (CA). An Azure AD CA is essentially a mini-CA cloud tenant in Azure. The Azure AD CA cannot be configured as part of an on-premises Enterprise CA.
See also [Always On VPN deployment for Windows Server and Windows 10](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy).
- Azure AD-issued short-lived certificates - When a VPN connection attempt is made, the Azure AD Token Broker on the local device communicates with Azure Active Directory, which then checks for health based on compliance rules. If compliant, Azure AD sends back a short-lived certificate that is used to authenticate the VPN. Note that certificate authentication methods such as EAP-TLS can be used. When the client reconnects and determines that the certificate has expired, the client will again check with Azure AD for health validation before a new certificate is issued.
- [Microsoft Intune device compliance policies](/mem/intune/protect/device-compliance-get-started) - Cloud-based device compliance leverages Microsoft Intune Compliance Policies, which are capable of querying the device state and define compliance rules for the following, among other things.
- Antivirus status
- Auto-update status and update compliance
- Password policy compliance
- Encryption compliance
- Device health attestation state (validated against attestation service after query)
The following client-side components are also required:
- [HealthAttestation Configuration Service Provider (CSP)](/windows/client-management/mdm/healthattestation-csp)
- [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) DeviceCompliance node settings
- Trusted Platform Module (TPM)
## VPN device compliance
At this time, the Azure AD certificates issued to users do not contain a CRL Distribution Point (CDP) and are not suitable for Key Distribution Centers (KDCs) to issue Kerberos tokens. For users to gain access to on-premises resources such as files on a network share, client authentication certificates must be deployed to the Windows profiles of the users, and their VPNv2 profiles must contain the &lt;SSO&gt; section.
Server-side infrastructure requirements to support VPN device compliance include:
- The VPN server should be configured for certificate authentication.
- The VPN server should trust the tenant-specific Azure AD CA.
- For client access using Kerberos/NTLM, a domain-trusted certificate is deployed to the client device and is configured to be used for single sign-on (SSO).
After the server side is set up, VPN admins can add the policy settings for conditional access to the VPN profile using the VPNv2 DeviceCompliance node.
Two client-side configuration service providers are leveraged for VPN device compliance.
- VPNv2 CSP DeviceCompliance settings:
- **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Azure AD to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Azure AD.
- **Sso**: entries under SSO should be used to direct the VPN client to use a certificate other than the VPN authentication certificate when accessing resources that require Kerberos authentication.
- **Sso/Enabled**: if this field is set to **true**, the VPN client looks for a separate certificate for Kerberos authentication.
- **Sso/IssuerHash**: hashes for the VPN client to look for the correct certificate for Kerberos authentication.
- **Sso/Eku**: comma-separated list of extended key usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication.
- HealthAttestation CSP (not a requirement) - functions performed by the HealthAttestation CSP include:
- Collects TPM data used to verify health states
- Forwards the data to the Health Attestation Service (HAS)
- Provisions the Health Attestation Certificate received from the HAS
- Upon request, forward the Health Attestation Certificate (received from HAS) and related runtime information to the MDM server for verification
> [!NOTE]
> It's required that certificates used for obtaining Kerberos tickets to be issued from an on-premises CA, and that SSO to be enabled in the user's VPN profile. This will enable the user to access on-premises resources.
> In the case of AzureAD-only joined devices (not hybrid joined devices), if the user certificate issued by the on-premises CA has the user UPN from AzureAD in Subject and SAN (Subject Alternative Name), the VPN profile must be modified to ensure that the client does not cache the credentials used for VPN authentication. To do this, after deploying the VPN profile to the client, modify the *Rasphone.pbk* on the client by changing the entry **UseRasCredentials** from 1 (default) to 0 (zero).
## Client connection flow
The VPN client side connection flow works as follows:
![Device compliance workflow when VPN client attempts to connect.](images/vpn-device-compliance.png)
When a VPNv2 Profile is configured with \<DeviceCompliance> \<Enabled>true<\/Enabled> the VPN client uses this connection flow:
1. The VPN client calls into Windows 10's or Windows 11's Azure AD Token Broker, identifying itself as a VPN client.
1. The Azure AD Token Broker authenticates to Azure AD and provides it with information about the device trying to connect. The Azure AD Server checks if the device is in compliance with the policies.
1. If compliant, Azure AD requests a short-lived certificate.
1. Azure AD pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing.
1. The VPN client uses the Azure AD-issued certificate to authenticate with the VPN server.
## Configure conditional access
See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
## Learn more about Conditional Access and Azure AD Health
- [Azure Active Directory conditional access](/azure/active-directory/conditional-access/overview)
- [Getting started with Azure Active Directory Conditional Access](/azure/active-directory/authentication/tutorial-enable-azure-mfa)
- [Control the health of Windows devices](../../../threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md)
- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 1)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn)
- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 2)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn-part-2)
- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 3)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn-part-3)
- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 4)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn-part-4)
## Related topics
- [VPN technical guide](vpn-guide.md)
- [VPN connection types](vpn-connection-type.md)
- [VPN routing decisions](vpn-routing.md)
- [VPN authentication options](vpn-authentication.md)
- [VPN name resolution](vpn-name-resolution.md)
- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
- [VPN security features](vpn-security-features.md)
- [VPN profile options](vpn-profile-options.md)

View File

@ -0,0 +1,57 @@
---
title: VPN connection types (Windows 10 and Windows 11)
description: Learn about Windows VPN platform clients and the VPN connection-type features that can be configured.
ms.date: 05/24/2022
ms.topic: conceptual
---
# VPN connection types
VPNs are point-to-point connections across a private or public network, like the Internet. A VPN client uses special TCP/IP or UDP-based protocols, called *tunneling protocols*, to make a virtual call to a virtual port on a VPN server. In a typical VPN deployment, a client initiates a virtual point-to-point connection to a remote access server over the Internet. The remote access server answers the call, authenticates the caller, and transfers data between the VPN client and the organization's private network.
There are many options for VPN clients. In Windows, the built-in plug-in and the Universal Windows Platform (UWP) VPN plug-in platform are built on top of the Windows VPN platform. This article focuses on the Windows VPN platform clients and the features that can be configured.
![VPN connection types.](images/vpn-connection.png)
## Built-in VPN client
Tunneling protocols:
- [Internet Key Exchange version 2 (IKEv2)](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff687731(v=ws.10)): configure the IPsec/IKE tunnel cryptographic properties using the **Cryptography Suite** setting in the [VPNv2 Configuration Service Provider (CSP)](/windows/client-management/mdm/vpnv2-csp).
- [L2TP](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff687761(v=ws.10)): L2TP with pre-shared key (PSK) authentication can be configured using the **L2tpPsk** setting in the [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp).
- [PPTP](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff687676(v=ws.10))
- [SSTP](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff687819(v=ws.10)): SSTP can't be configured using MDM, but it's one of the protocols attempted in the **Automatic** option
> [!NOTE]
> When a VPN plug-in is used, the adapter will be listed as an SSTP adapter, even though the VPN protocol used is the plug-in's protocol.
- Automatic: the **Automatic** option means that the device tries each of the built-in tunneling protocols until one succeeds. It attempts from most secure to least secure. Configure **Automatic** for the **NativeProtocolType** setting in the [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp).
## Universal Windows Platform VPN plug-in
Using the UWP platform, third-party VPN providers can create app-containerized plug-ins using WinRT APIs, eliminating the complexity and problems often associated with writing to system-level drivers.
There are many Universal Windows Platform VPN applications, such as Pulse Secure, Cisco AnyConnect, F5 Access, Sonicwall Mobile Connect, and Check Point Capsule. If you want to use a UWP VPN plug-in, work with your vendor for any custom settings needed to configure your VPN solution.
## Configure connection type
See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
The following image shows connection options in a VPN Profile configuration policy using Microsoft Intune:
> [!div class="mx-imgBorder"]
> ![Available connection types.](images/vpn-connection-intune.png)
In Intune, you can also include custom XML for third-party plug-in profiles:
> [!div class="mx-imgBorder"]
> ![Custom XML.](images/vpn-custom-xml-intune.png)
## Related articles
- [VPN technical guide](vpn-guide.md)
- [VPN routing decisions](vpn-routing.md)
- [VPN authentication options](vpn-authentication.md)
- [VPN and conditional access](vpn-conditional-access.md)
- [VPN name resolution](vpn-name-resolution.md)
- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
- [VPN security features](vpn-security-features.md)
- [VPN profile options](vpn-profile-options.md)

View File

@ -0,0 +1,34 @@
---
title: Windows VPN technical guide
description: Learn how to plan and configure Windows devices for your organization's VPN solution.
ms.date: 05/24/2023
ms.topic: conceptual
---
# Windows VPN technical guide
This guide walks you through the decisions to make for Windows clients in your organization's VPN solution, and how to configure your devices. This guide references the [VPNv2 Configuration Service Provider (CSP)](/windows/client-management/mdm/vpnv2-csp) and provides mobile device management (MDM) configuration instructions using Microsoft Intune.
To create a Windows VPN device configuration profile see: [Windows device settings to add VPN connections using Intune](/mem/intune/configuration/vpn-settings-windows-10).
> [!NOTE]
> This guide does not explain server deployment.
[!INCLUDE [virtual-private-network-vpn](../../../../../includes/licensing/virtual-private-network-vpn.md)]
## In this guide
| Article | Description |
| --- | --- |
| [VPN connection types](vpn-connection-type.md) | Select a VPN client and tunneling protocol |
| [VPN routing decisions](vpn-routing.md) | Choose between split tunnel and force tunnel configuration |
| [VPN authentication options](vpn-authentication.md) | Select a method for Extensible Authentication Protocol (EAP) authentication. |
| [VPN and conditional access](vpn-conditional-access.md) | Use Azure Active Directory policy evaluation to set access policies for VPN connections. |
| [VPN name resolution](vpn-name-resolution.md) | Decide how name resolution should work |
| [VPN auto-triggered profile options](vpn-auto-trigger-profile.md) | Set a VPN profile to connect automatically by app or by name, to be "always on", and to not trigger VPN on trusted networks |
| [VPN security features](vpn-security-features.md) | Configure traffic filtering, connect a VPN profile to Windows Information Protection (WIP), and more |
| [VPN profile options](vpn-profile-options.md) | Combine settings into single VPN profile using XML |
## Learn more
- [Create VPN profiles to connect to VPN servers in Intune](/mem/intune/configuration/vpn-settings-configure)

View File

@ -0,0 +1,71 @@
---
title: VPN name resolution
description: Learn how name resolution works when using a VPN connection.
ms.date: 05/24/2023
ms.topic: conceptual
---
# VPN name resolution
When the VPN client establishes a connection, it receives an IP address and, optionally, the IP address of one or more DNS servers.
The name resolution setting in the VPN profile determines how name resolution works on the system when the VPN connection is established:
1. The network stack looks at the Name Resolution Policy table (NRPT) for any matches, and tries a resolution if a match is found
1. If no match is found, the DNS suffix on the most preferred interface based on the interface metric is appended to the name (if a short name is used). A DNS query is sent to the preferred interface
1. If the query times out, the DNS suffix search list is used in order and DNS queries are sent on all interfaces
## Name Resolution Policy table (NRPT)
The NRPT is a table of namespaces that determines the DNS client's behavior when issuing name resolution queries and processing responses. It's the first place that the stack will look after the DNSCache.
There are three types of name matches that can set up for NRPT:
- Fully qualified domain name (FQDN) that can be used for direct matching to a name
- Suffix match results in either a comparison of suffixes (for FQDN resolution) or the appending of the suffix (if using short name)
- Any resolution should attempt to first resolve with the proxy server/DNS server with this entry
NRPT is set using the `VPNv2/<ProfileName>/DomainNameInformationList` node of the [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp). You can use the same node to configure a Web proxy server or DNS.
To learn more about NRPT, see [Introduction to the NRPT](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee649207(v=ws.10)).
## DNS suffix
The DNS suffix setting is used to configure the primary DNS suffix for the VPN interface and the suffix search list after the VPN connection is established.
Primary DNS suffix is set using the `VPNv2/<ProfileName>/DnsSuffix` node.
[Learn more about primaryDNS suffix](/previous-versions/windows/it-pro/windows-2000-server/cc959611(v=technet.10))
## Persistent name resolution rules
You can configure *persistent* name resolution rules. Name resolution for the specified items is done over the VPN.
Persistent name resolution is set using the `VPNv2/<ProfileName>/DomainNameInformationList/<dniRowId>/Persistent` node.
## Configure name resolution
See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
The following image shows name resolution options in a VPN Profile configuration policy using Microsoft Intune.
:::image type="content" source="images/vpn-name-intune.png" alt-text="Creation of VPN profile in Intune: DNS options." lightbox="images/vpn-name-intune.png":::
The fields in **Add or edit DNS rule** in the Intune profile correspond to the XML settings shown in the following table.
| Field | XML |
| --- | --- |
| **Name** | **VPNv2/*ProfileName*/DomainNameInformationList/*dniRowId*/DomainName** |
| **Servers (comma separated)** | **VPNv2/*ProfileName*/DomainNameInformationList/*dniRowId*/DnsServers** |
| **Proxy server** | **VPNv2/*ProfileName*/DomainNameInformationList/*dniRowId*/WebServers** |
## Related articles
- [VPN technical guide](vpn-guide.md)
- [VPN connection types](vpn-connection-type.md)
- [VPN routing decisions](vpn-routing.md)
- [VPN authentication options](vpn-authentication.md)
- [VPN and conditional access](vpn-conditional-access.md)
- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
- [VPN security features](vpn-security-features.md)
- [VPN profile options](vpn-profile-options.md)

View File

@ -0,0 +1,650 @@
---
title: Optimize Microsoft 365 traffic for remote workers with the Windows VPN client
description: Learn how to optimize Microsoft 365 traffic for remote workers with the Windows VPN client
ms.topic: article
ms.date: 05/24/2023
---
# Optimize Microsoft 365 traffic for remote workers with the Windows VPN client
This article describes how to configure the recommendations in the article [VPN split tunneling for Microsoft 365](/microsoft-365/enterprise/microsoft-365-vpn-split-tunnel) for the Windows VPN client. This guidance enables VPN administrators to optimize Microsoft 365 usage while ensuring that all other traffic goes over the VPN connection and through existing security gateways or tooling.
The recommendations can be implemented for the built-in Windows VPN client using a *Force Tunneling with Exclusions* approach, defining IP-based exclusions even when using *force tunneling*. Certain traffic can be *split* to use the physical interface, while still forcing all other traffic via the VPN interface. Traffic addressed to defined destinations (like those listed in the Microsoft 365 optimized categories) follows a much more direct and efficient path, without the need to traverse or *hairpin* via the VPN tunnel and back out of the organization's network. For cloud-services like Microsoft 365, this makes a significant difference in performance and usability for remote users.
> [!NOTE]
> The term *force tunneling with exclusions* is sometimes confusingly called *split tunnels* by other vendors and in some online documentation. For Windows VPN, the term *split tunneling* is defined differently, as described in the article [VPN routing decisions](./vpn-routing.md#split-tunnel-configuration).
## Solution Overview
The solution is based upon the use of a VPN Configuration Service Provider Reference profile ([VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp)) and the embedded [ProfileXML](/windows/client-management/mdm/vpnv2-profile-xsd). These are used to configure the VPN profile on the device. Various provisioning approaches can be used to create and deploy the VPN profile as discussed in the article [Step 6. Configure Windows 10 client Always On VPN connections](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#create-the-profilexml-configuration-files).
Typically, these VPN profiles are distributed using a Mobile Device Management solution like Intune, as described in [VPN profile options](./vpn-profile-options.md#apply-profilexml-using-intune) and [Configure the VPN client by using Intune](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#configure-the-vpn-client-by-using-intune).
To enable the use of force tunneling in Windows 10 or Windows 11 VPN, the `<RoutingPolicyType>` setting is typically configured with a value of _ForceTunnel_ in your existing Profile XML (or script) by way of the following entry, under the `<NativeProfile></NativeProfile>` section:
```xml
<RoutingPolicyType>ForceTunnel</RoutingPolicyType>
```
In order to define specific force tunnel exclusions, you then need to add the following lines to your existing Profile XML (or script) for each required exclusion, and place them outside of the `<NativeProfile></NativeProfile>` section as follows:
```xml
<Route>
<Address>[IP addresses or subnet]</Address>
<PrefixSize>[IP Prefix]</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
```
Entries defined by the `[IP Addresses or Subnet]` and `[IP Prefix]` references will consequently be added to the routing table as _more specific route entries_ that will use the Internet-connected interface as the default gateway, as opposed to using the VPN interface. You must define a unique and separate `<Route></Route>` section for each required exclusion.
An example of a correctly formatted Profile XML configuration for force tunnel with exclusions is the following:
```xml
<VPNProfile>
<NativeProfile>
<RoutingPolicyType>ForceTunnel</RoutingPolicyType>
</NativeProfile>
<Route>
<Address>203.0.113.0</Address>
<PrefixSize>24</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>198.51.100.0</Address>
<PrefixSize>22</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
</VPNProfile>
```
> [!NOTE]
> The IP addresses and prefix size values in this example are used purely as examples only and should not be used.
## Solution Deployment
For Microsoft 365, it's therefore necessary to add exclusions for all IP addresses documented within the optimize categories described in [Office 365 URLs and IP address ranges](/microsoft-365/enterprise/urls-and-ip-address-ranges) to ensure that they're excluded from VPN force tunneling.
This can be achieved manually by adding the IP addresses defined within the *optimize* category entries to an existing Profile XML (or script) file, or alternatively the following script can be used which dynamically adds the required entries to an existing PowerShell script, or XML file, based upon directly querying the REST-based web service to ensure the correct IP address ranges are always used.
An example of a PowerShell script that can be used to update a force tunnel VPN connection with Microsoft 365 exclusions is provided below.
```powershell
# Copyright (c) Microsoft Corporation. All rights reserved.
#
# THIS SAMPLE CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
# WHETHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
# IF THIS CODE AND INFORMATION IS MODIFIED, THE ENTIRE RISK OF USE OR RESULTS IN
# CONNECTION WITH THE USE OF THIS CODE AND INFORMATION REMAINS WITH THE USER.
<#
.SYNOPSIS
Applies or updates recommended Microsoft 365 optimize IP address exclusions to an existing force tunnel Windows 10 and Windows 11 VPN profile
.DESCRIPTION
Connects to the Microsoft 365 worldwide commercial service instance endpoints to obtain the latest published IP address ranges
Compares the optimized IP addresses with those contained in the supplied VPN Profile (PowerShell or XML file)
Adds or updates IP addresses as necessary and saves the resultant file with "-NEW" appended to the file name
.PARAMETERS
Filename and path for a supplied Windows 10 or Windows 11 VPN profile file in either PowerShell or XML format
.NOTES
Requires at least Windows 10 Version 1803 with KB4493437, 1809 with KB4490481, or later
.VERSION
1.0
#>
param (
[string]$VPNprofilefile
)
$usage=@"
This script uses the following parameters:
VPNprofilefile - The full path and name of the VPN profile PowerShell script or XML file
EXAMPLES
To check a VPN profile PowerShell script file:
Update-VPN-Profile-Office365-Exclusion-Routes.ps1 -VPNprofilefile [FULLPATH AND NAME OF POWERSHELL SCRIPT FILE]
To check a VPN profile XML file:
Update-VPN-Profile-Office365-Exclusion-Routes.ps1 -VPNprofilefile [FULLPATH AND NAME OF XML FILE]
"@
# Check if filename has been provided #
if ($VPNprofilefile -eq "")
{
Write-Host "`nWARNING: You must specify either a PowerShell script or XML filename!" -ForegroundColor Red
$usage
exit
}
$FileExtension = [System.IO.Path]::GetExtension($VPNprofilefile)
# Check if XML file exists and is a valid XML file #
if ( $VPNprofilefile -ne "" -and $FileExtension -eq ".xml")
{
if ( Test-Path $VPNprofilefile )
{
$xml = New-Object System.Xml.XmlDocument
try
{
$xml.Load((Get-ChildItem -Path $VPNprofilefile).FullName)
}
catch [System.Xml.XmlException]
{
Write-Verbose "$VPNprofilefile : $($_.toString())"
Write-Host "`nWARNING: The VPN profile XML file is not a valid xml file or incorrectly formatted!" -ForegroundColor Red
$usage
exit
}
}else
{
Write-Host "`nWARNING: VPN profile XML file does not exist or cannot be found!" -ForegroundColor Red
$usage
exit
}
}
# Check if VPN profile PowerShell script file exists and contains a VPNPROFILE XML section #
if ( $VPNprofilefile -ne "" -and $FileExtension -eq ".ps1")
{
if ( (Test-Path $VPNprofilefile) )
{
if (-Not $(Select-String -Path $VPNprofilefile -Pattern "<VPNPROFILE>") )
{
Write-Host "`nWARNING: PowerShell script file does not contain a valid VPN profile XML section or is incorrectly formatted!" -ForegroundColor Red
$usage
exit
}
}else
{
Write-Host "`nWARNING: PowerShell script file does not exist or cannot be found!"-ForegroundColor Red
$usage
exit
}
}
# Define Microsoft 365 endpoints and service URLs #
$ws = "https://endpoints.office.com"
$baseServiceUrl = "https://endpoints.office.com"
# Path where client ID and latest version number will be stored #
$datapath = $Env:TEMP + "\endpoints_clientid_latestversion.txt"
# Fetch client ID and version if data file exists; otherwise create new file #
if (Test-Path $datapath)
{
$content = Get-Content $datapath
$clientRequestId = $content[0]
$lastVersion = $content[1]
}else
{
$clientRequestId = [GUID]::NewGuid().Guid
$lastVersion = "0000000000"
@($clientRequestId, $lastVersion) | Out-File $datapath
}
# Call version method to check the latest version, and pull new data if version number is different #
$version = Invoke-RestMethod -Uri ($ws + "/version?clientRequestId=" + $clientRequestId)
if ($version[0].latest -gt $lastVersion)
{
Write-Host
Write-Host "A new version of Microsoft 365 worldwide commercial service instance endpoints has been detected!" -ForegroundColor Cyan
# Write the new version number to the data file #
@($clientRequestId, $version[0].latest) | Out-File $datapath
}
# Invoke endpoints method to get the new data #
$uri = "$baseServiceUrl" + "/endpoints/worldwide?clientRequestId=$clientRequestId"
# Invoke endpoints method to get the data for the VPN profile comparison #
$endpointSets = Invoke-RestMethod -Uri ($uri)
$Optimize = $endpointSets | Where-Object { $_.category -eq "Optimize" }
$optimizeIpsv4 = $Optimize.ips | Where-Object { ($_).contains(".") } | Sort-Object -Unique
# Temporarily include additional IP address until Teams client update is released
$optimizeIpsv4 += "13.107.60.1/32"
# Process PowerShell script file start #
if ($VPNprofilefile -ne "" -and $FileExtension -eq ".ps1")
{
Write-host "`nStarting PowerShell script exclusion route check...`n" -ForegroundColor Cyan
# Clear Variables to allow re-run testing #
$ARRVPN=$null # Array to hold VPN addresses from VPN profile PowerShell file #
$In_Opt_Only=$null # Variable to hold IP addresses that only appear in the optimize list #
$In_VPN_Only=$null # Variable to hold IP addresses that only appear in the VPN profile PowerShell file #
# Extract the Profile XML from the ps1 file #
$regex = '(?sm).*^*.<VPNProfile>\r?\n(.*?)\r?\n</VPNProfile>.*'
# Create xml format variable to compare with the optimize list #
$xmlbody=(Get-Content -Raw $VPNprofilefile) -replace $regex, '$1'
[xml]$VPNprofilexml="<VPNProfile>"+$xmlbody+"</VPNProfile>"
# Loop through each address found in VPNPROFILE XML section #
foreach ($Route in $VPNprofilexml.VPNProfile.Route)
{
$VPNIP=$Route.Address+"/"+$Route.PrefixSize
[array]$ARRVPN=$ARRVPN+$VPNIP
}
# In optimize address list only #
$In_Opt_Only= $optimizeIpsv4 | Where {$ARRVPN -NotContains $_}
# In VPN list only #
$In_VPN_only =$ARRVPN | Where {$optimizeIpsv4 -NotContains $_}
[array]$Inpfile = get-content $VPNprofilefile
if ($In_Opt_Only.Count -gt 0 )
{
Write-Host "Exclusion route IP addresses are unknown, missing, or need to be updated in the VPN profile`n" -ForegroundColor Red
[int32]$insline=0
for ($i=0; $i -lt $Inpfile.count; $i++)
{
if ($Inpfile[$i] -match "</NativeProfile>")
{
$insline += $i # Record the position of the line after the NativeProfile section ends #
}
}
$OFS = "`r`n"
foreach ($NewIP in $In_Opt_Only)
{
# Add the missing IP address(es) #
$IPInfo=$NewIP.Split("/")
$InpFile[$insline] += $OFS+" <Route>"
$InpFile[$insline] += $OFS+" <Address>"+$IPInfo[0].Trim()+"</Address>"
$InpFile[$insline] += $OFS+" <PrefixSize>"+$IPInfo[1].Trim()+"</PrefixSize>"
$InpFile[$insline] += $OFS+" <ExclusionRoute>true</ExclusionRoute>"
$InpFile[$insline] += $OFS+" </Route>"
}
# Update fileName and write new PowerShell file #
$NewFileName=(Get-Item $VPNprofilefile).Basename + "-NEW.ps1"
$OutFile=$(Split-Path $VPNprofilefile -Parent)+"\"+$NewFileName
$InpFile | Set-Content $OutFile
Write-Host "Exclusion routes have been added to VPN profile and output to a separate PowerShell script file; the original file has not been modified`n" -ForegroundColor Green
}else
{
Write-Host "Exclusion route IP addresses are correct and up to date in the VPN profile`n" -ForegroundColor Green
$OutFile=$VPNprofilefile
}
if ( $In_VPN_Only.Count -gt 0 )
{
Write-Host "Unknown exclusion route IP addresses have been found in the VPN profile`n" -ForegroundColor Yellow
foreach ($OldIP in $In_VPN_Only)
{
[array]$Inpfile = get-content $Outfile
$IPInfo=$OldIP.Split("/")
Write-Host "Unknown exclusion route IP address"$IPInfo[0]"has been found in the VPN profile - Do you wish to remove it? (Y/N)`n" -ForegroundColor Yellow
$matchstr="<Address>"+$IPInfo[0].Trim()+"</Address>"
$DelAns=Read-host
if ($DelAns.ToUpper() -eq "Y")
{
[int32]$insline=0
for ($i=0; $i -lt $Inpfile.count; $i++)
{
if ($Inpfile[$i] -match $matchstr)
{
$insline += $i # Record the position of the line for the string match #
}
}
# Remove entries from XML #
$InpFile[$insline-1]="REMOVETHISLINE"
$InpFile[$insline]="REMOVETHISLINE"
$InpFile[$insline+1]="REMOVETHISLINE"
$InpFile[$insline+2]="REMOVETHISLINE"
$InpFile[$insline+3]="REMOVETHISLINE"
$InpFile=$InpFile | Where-Object {$_ -ne "REMOVETHISLINE"}
# Update filename and write new PowerShell file #
$NewFileName=(Get-Item $VPNprofilefile).Basename + "-NEW.xml"
$OutFile=$(Split-Path $VPNprofilefile -Parent)+"\"+$NewFileName
$Inpfile | Set-content $OutFile
Write-Host "`nAddress"$IPInfo[0]"exclusion route has been removed from the VPN profile and output to a separate PowerShell script file; the original file has not been modified`n" -ForegroundColor Green
}else
{
Write-Host "`nExclusion route IP address has *NOT* been removed from the VPN profile`n" -ForegroundColor Green
}
}
}
}
# Process XML file start #
if ($VPNprofilefile -ne "" -and $FileExtension -eq ".xml")
{
Write-host "`nStarting XML file exclusion route check...`n" -ForegroundColor Cyan
# Clear variables to allow re-run testing #
$ARRVPN=$null # Array to hold VPN addresses from the XML file #
$In_Opt_Only=$null # Variable to hold IP Addresses that only appear in optimize list #
$In_VPN_Only=$null # Variable to hold IP Addresses that only appear in the VPN profile XML file #
# Extract the Profile XML from the XML file #
$regex = '(?sm).*^*.<VPNProfile>\r?\n(.*?)\r?\n</VPNProfile>.*'
# Create xml format variable to compare with optimize list #
$xmlbody=(Get-Content -Raw $VPNprofilefile) -replace $regex, '$1'
[xml]$VPNRulesxml="$xmlbody"
# Loop through each address found in VPNPROFILE file #
foreach ($Route in $VPNRulesxml.VPNProfile.Route)
{
$VPNIP=$Route.Address+"/"+$Route.PrefixSize
[array]$ARRVPN=$ARRVPN+$VPNIP
}
# In optimize address list only #
$In_Opt_Only= $optimizeIpsv4 | Where {$ARRVPN -NotContains $_}
# In VPN list only #
$In_VPN_only =$ARRVPN | Where {$optimizeIpsv4 -NotContains $_}
[System.Collections.ArrayList]$Inpfile = get-content $VPNprofilefile
if ($In_Opt_Only.Count -gt 0 )
{
Write-Host "Exclusion route IP addresses are unknown, missing, or need to be updated in the VPN profile`n" -ForegroundColor Red
foreach ($NewIP in $In_Opt_Only)
{
# Add the missing IP address(es) #
$IPInfo=$NewIP.Split("/")
$routes += "<Route>`n"+"`t<Address>"+$IPInfo[0].Trim()+"</Address>`n"+"`t<PrefixSize>"+$IPInfo[1].Trim()+"</PrefixSize>`n"+"`t<ExclusionRoute>true</ExclusionRoute>`n"+"</Route>`n"
}
$inspoint = $Inpfile.IndexOf("</VPNProfile>")
$Inpfile.Insert($inspoint,$routes)
# Update filename and write new XML file #
$NewFileName=(Get-Item $VPNprofilefile).Basename + "-NEW.xml"
$OutFile=$(Split-Path $VPNprofilefile -Parent)+"\"+$NewFileName
$InpFile | Set-Content $OutFile
Write-Host "Exclusion routes have been added to VPN profile and output to a separate XML file; the original file has not been modified`n`n" -ForegroundColor Green
}else
{
Write-Host "Exclusion route IP addresses are correct and up to date in the VPN profile`n" -ForegroundColor Green
$OutFile=$VPNprofilefile
}
if ( $In_VPN_Only.Count -gt 0 )
{
Write-Host "Unknown exclusion route IP addresses found in the VPN profile`n" -ForegroundColor Yellow
foreach ($OldIP in $In_VPN_Only)
{
[array]$Inpfile = get-content $OutFile
$IPInfo=$OldIP.Split("/")
Write-Host "Unknown exclusion route IP address"$IPInfo[0]"has been found in the VPN profile - Do you wish to remove it? (Y/N)`n" -ForegroundColor Yellow
$matchstr="<Route>"+"<Address>"+$IPInfo[0].Trim()+"</Address>"+"<PrefixSize>"+$IPInfo[1].Trim()+"</PrefixSize>"+"<ExclusionRoute>true</ExclusionRoute>"+"</Route>"
$DelAns=Read-host
if ($DelAns.ToUpper() -eq "Y")
{
# Remove unknown IP address(es) #
$inspoint = $Inpfile[0].IndexOf($matchstr)
$Inpfile[0] = $Inpfile[0].Replace($matchstr,"")
# Update filename and write new XML file #
$NewFileName=(Get-Item $VPNprofilefile).Basename + "-NEW.xml"
$OutFile=$(Split-Path $VPNprofilefile -Parent)+"\"+$NewFileName
$Inpfile | Set-content $OutFile
Write-Host "`nAddress"$IPInfo[0]"exclusion route has been removed from the VPN profile and output to a separate XML file; the original file has not been modified`n" -ForegroundColor Green
}else
{
Write-Host "`nExclusion route IP address has *NOT* been removed from the VPN profile`n" -ForegroundColor Green
}
}
}
}
```
## Other Considerations
You should also be able to adapt this approach to include necessary exclusions for other cloud-services that can be defined by known/static IP addresses; exclusions required for [Cisco WebEx](https://help.webex.com/WBX000028782/Network-Requirements-for-Webex-Teams-Services) or [Zoom](https://support.zoom.us/hc/en-us/articles/201362683) are good examples.
## Examples
An example of a PowerShell script that can be used to create a force tunnel VPN connection with Microsoft 365 exclusions is provided below, or refer to the guidance in [Create the ProfileXML configuration files](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#create-the-profilexml-configuration-files) to create the initial PowerShell script:
```powershell
# Copyright (c) Microsoft Corporation. All rights reserved.
#
# THIS SAMPLE CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
# WHETHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
# IF THIS CODE AND INFORMATION IS MODIFIED, THE ENTIRE RISK OF USE OR RESULTS IN
# CONNECTION WITH THE USE OF THIS CODE AND INFORMATION REMAINS WITH THE USER.
<#
.SYNOPSIS
Configures an AlwaysOn IKEv2 VPN Connection using a basic script
.DESCRIPTION
Configures an AlwaysOn IKEv2 VPN Connection with proxy PAC information and force tunneling
.PARAMETERS
Parameters are defined in a ProfileXML object within the script itself
.NOTES
Requires at least Windows 10 Version 1803 with KB4493437, 1809 with KB4490481, or later
.VERSION
1.0
#>
<#-- Define Key VPN Profile Parameters --#>
$ProfileName = 'Contoso VPN with Microsoft 365 Exclusions'
$ProfileNameEscaped = $ProfileName -replace ' ', '%20'
<#-- Define VPN ProfileXML --#>
$ProfileXML = '<VPNProfile>
<RememberCredentials>true</RememberCredentials>
<DnsSuffix>corp.contoso.com</DnsSuffix>
<AlwaysOn>true</AlwaysOn>
<TrustedNetworkDetection>corp.contoso.com</TrustedNetworkDetection>
<NativeProfile>
<Servers>edge1.contoso.com</Servers>
<RoutingPolicyType>ForceTunnel</RoutingPolicyType>
<NativeProtocolType>IKEv2</NativeProtocolType>
<Authentication>
<MachineMethod>Certificate</MachineMethod>
</Authentication>
</NativeProfile>
<Route>
<Address>13.107.6.152</Address>
<PrefixSize>31</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>13.107.18.10</Address>
<PrefixSize>31</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>13.107.128.0</Address>
<PrefixSize>22</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>23.103.160.0</Address>
<PrefixSize>20</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>40.96.0.0</Address>
<PrefixSize>13</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>40.104.0.0</Address>
<PrefixSize>15</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>52.96.0.0</Address>
<PrefixSize>14</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>131.253.33.215</Address>
<PrefixSize>32</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>132.245.0.0</Address>
<PrefixSize>16</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>150.171.32.0</Address>
<PrefixSize>22</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>191.234.140.0</Address>
<PrefixSize>22</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>204.79.197.215</Address>
<PrefixSize>32</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>13.107.136.0</Address>
<PrefixSize>22</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>40.108.128.0</Address>
<PrefixSize>17</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>52.104.0.0</Address>
<PrefixSize>14</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>104.146.128.0</Address>
<PrefixSize>17</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>150.171.40.0</Address>
<PrefixSize>22</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>13.107.60.1</Address>
<PrefixSize>32</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>13.107.64.0</Address>
<PrefixSize>18</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>52.112.0.0</Address>
<PrefixSize>14</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Route>
<Address>52.120.0.0</Address>
<PrefixSize>14</PrefixSize>
<ExclusionRoute>true</ExclusionRoute>
</Route>
<Proxy>
<AutoConfigUrl>http://webproxy.corp.contoso.com/proxy.pac</AutoConfigUrl>
</Proxy>
</VPNProfile>'
<#-- Convert ProfileXML to Escaped Format --#>
$ProfileXML = $ProfileXML -replace '<', '&lt;'
$ProfileXML = $ProfileXML -replace '>', '&gt;'
$ProfileXML = $ProfileXML -replace '"', '&quot;'
<#-- Define WMI-to-CSP Bridge Properties --#>
$nodeCSPURI = './Vendor/MSFT/VPNv2'
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_VPNv2_01"
<#-- Define WMI Session --#>
$session = New-CimSession
<#-- Detect and Delete Previous VPN Profile --#>
try
{
$deleteInstances = $session.EnumerateInstances($namespaceName, $className, $options)
foreach ($deleteInstance in $deleteInstances)
{
$InstanceId = $deleteInstance.InstanceID
if ("$InstanceId" -eq "$ProfileNameEscaped")
{
$session.DeleteInstance($namespaceName, $deleteInstance, $options)
$Message = "Removed $ProfileName profile $InstanceId"
Write-Host "$Message"
} else {
$Message = "Ignoring existing VPN profile $InstanceId"
Write-Host "$Message"
}
}
}
catch [Exception]
{
$Message = "Unable to remove existing outdated instance(s) of $ProfileName profile: $_"
Write-Host "$Message"
exit
}
<#-- Create VPN Profile --#>
try
{
$newInstance = New-Object Microsoft.Management.Infrastructure.CimInstance $className, $namespaceName
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ParentID", "$nodeCSPURI", 'String', 'Key')
$newInstance.CimInstanceProperties.Add($property)
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("InstanceID", "$ProfileNameEscaped", 'String', 'Key')
$newInstance.CimInstanceProperties.Add($property)
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ProfileXML", "$ProfileXML", 'String', 'Property')
$newInstance.CimInstanceProperties.Add($property)
$session.CreateInstance($namespaceName, $newInstance, $options)
$Message = "Created $ProfileName profile."
Write-Host "$Message"
Write-Host "$ProfileName profile summary:"
$session.EnumerateInstances($namespaceName, $className, $options)
}
catch [Exception]
{
$Message = "Unable to create $ProfileName profile: $_"
Write-Host "$Message"
exit
}
$Message = "Script Complete"
Write-Host "$Message"
```
An example of an [Intune-ready XML file](./vpn-profile-options.md#apply-profilexml-using-intune) that can be used to create a force tunnel VPN connection with Microsoft 365 exclusions is provided below, or refer to the guidance in [Create the ProfileXML configuration files](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#create-the-profilexml-configuration-files) to create the initial XML file.
>[!NOTE]
>This XML is formatted for use with Intune and cannot contain any carriage returns or whitespace.
```xml
<VPNProfile><RememberCredentials>true</RememberCredentials><DnsSuffix>corp.contoso.com</DnsSuffix><AlwaysOn>true</AlwaysOn><TrustedNetworkDetection>corp.contoso.com</TrustedNetworkDetection><NativeProfile><Servers>edge1.contoso.com</Servers><RoutingPolicyType>ForceTunnel</RoutingPolicyType><NativeProtocolType>IKEv2</NativeProtocolType><Authentication><MachineMethod>Certificate</MachineMethod></Authentication></NativeProfile><Route><Address>13.107.6.152</Address><PrefixSize>31</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.18.10</Address><PrefixSize>31</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.128.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>23.103.160.0</Address><PrefixSize>20</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>40.96.0.0</Address><PrefixSize>13</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>40.104.0.0</Address><PrefixSize>15</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>52.96.0.0</Address><PrefixSize>14</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>131.253.33.215</Address><PrefixSize>32</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>132.245.0.0</Address><PrefixSize>16</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>150.171.32.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>191.234.140.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>204.79.197.215</Address><PrefixSize>32</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.136.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>40.108.128.0</Address><PrefixSize>17</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>52.104.0.0</Address><PrefixSize>14</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>104.146.128.0</Address><PrefixSize>17</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>150.171.40.0</Address><PrefixSize>22</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.60.1</Address><PrefixSize>32</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>13.107.64.0</Address><PrefixSize>18</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>52.112.0.0</Address><PrefixSize>14</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Route><Address>52.120.0.0</Address><PrefixSize>14</PrefixSize><ExclusionRoute>true</ExclusionRoute></Route><Proxy><AutoConfigUrl>http://webproxy.corp.contoso.com/proxy.pac</AutoConfigUrl></Proxy></VPNProfile>
```

View File

@ -0,0 +1,329 @@
---
title: VPN profile options
description: Windows adds Virtual Private Network (VPN) profile options to help manage how users connect. VPNs give users secure remote access to the company network.
ms.date: 05/17/2018
ms.topic: conceptual
---
# VPN profile options
Most of the VPN settings in Windows 10 and Windows 11 can be configured in VPN profiles using Microsoft Intune or Microsoft Configuration Manager. All VPN settings in Windows 10 and Windows 11 can be configured using the **ProfileXML** node in the [VPNv2 configuration service provider (CSP)](/windows/client-management/mdm/vpnv2-csp).
>[!NOTE]
>If you're not familiar with CSPs, read [Introduction to configuration service providers (CSPs)](/windows/configuration/provisioning-packages/how-it-pros-can-use-configuration-service-providers) first.
The following table lists the VPN settings and whether the setting can be configured in Intune and Configuration Manager, or can only be configured using **ProfileXML**.
| Profile setting | Can be configured in Intune and Configuration Manager |
| --- | --- |
| Connection type | Yes |
| Routing: split-tunnel routes | Yes, except exclusion routes |
| Routing: forced-tunnel | Yes |
| Authentication (EAP) | Yes, if connection type is built in |
| Conditional access | Yes |
| Name resolution: NRPT | Yes |
| Name resolution: DNS suffix | No |
| Name resolution: persistent | No |
| Auto-trigger: app trigger | Yes |
| Auto-trigger: name trigger | Yes |
| Auto-trigger: Always On | Yes |
| Auto-trigger: trusted network detection | No |
| LockDown | No |
| Windows Information Protection (WIP) | Yes |
| Traffic filters | Yes |
| Proxy settings | Yes, by PAC/WPAD file or server and port |
> [!NOTE]
> VPN proxy settings are only used on Force Tunnel Connections. On Split Tunnel Connections, the general proxy settings are used.
The ProfileXML node was added to the VPNv2 CSP to allow users to deploy VPN profile as a single blob. This node is useful for deploying profiles with features that aren't yet supported by MDMs. You can get more examples in the [ProfileXML XSD](/windows/client-management/mdm/vpnv2-profile-xsd) article.
## Sample Native VPN profile
The following sample is a sample Native VPN profile. This blob would fall under the ProfileXML node.
```xml
<VPNProfile>
<ProfileName>TestVpnProfile</ProfileName>
<NativeProfile>
<Servers>testServer.VPN.com</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>
<!--Sample EAP profile (PEAP)-->
<Authentication>
<UserMethod>Eap</UserMethod>
<Eap>
<Configuration>
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<EapMethod>
<Type xmlns="http://www.microsoft.com/provisioning/EapCommon">25</Type>
<VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
<VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
<AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId>
</EapMethod>
<Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
<Type>25</Type>
<EapType xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV1">
<ServerValidation>
<DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
<ServerNames></ServerNames>
<TrustedRootCA>d2 d3 8e ba 60 ca a1 c1 20 55 a2 e1 c8 3b 15 ad 45 01 10 c2 </TrustedRootCA>
<TrustedRootCA>d1 76 97 cc 20 6e d2 6e 1a 51 f5 bb 96 e9 35 6d 6d 61 0b 74 </TrustedRootCA>
</ServerValidation>
<FastReconnect>true</FastReconnect>
<InnerEapOptional>false</InnerEapOptional>
<Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
<Type>13</Type>
<EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1">
<CredentialsSource>
<CertificateStore>
<SimpleCertSelection>true</SimpleCertSelection>
</CertificateStore>
</CredentialsSource>
<ServerValidation>
<DisableUserPromptForServerValidation>true</DisableUserPromptForServerValidation>
<ServerNames></ServerNames>
<TrustedRootCA>d2 d3 8e ba 60 ca a1 c1 20 55 a2 e1 c8 3b 15 ad 45 01 10 c2 </TrustedRootCA>
<TrustedRootCA>d1 76 97 cc 20 6e d2 6e 1a 51 f5 bb 96 e9 35 6d 6d 61 0b 74 </TrustedRootCA>
</ServerValidation>
<DifferentUsername>false</DifferentUsername>
<PerformServerValidation xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</PerformServerValidation>
<AcceptServerName xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</AcceptServerName>
<TLSExtensions xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">
<FilteringInfo xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV3">
<EKUMapping>
<EKUMap>
<EKUName>AAD Conditional Access</EKUName>
<EKUOID>1.3.6.1.4.1.311.87</EKUOID>
</EKUMap>
</EKUMapping>
<ClientAuthEKUList Enabled="true">
<EKUMapInList>
<EKUName>AAD Conditional Access</EKUName>
</EKUMapInList>
</ClientAuthEKUList>
</FilteringInfo>
</TLSExtensions>
</EapType>
</Eap>
<EnableQuarantineChecks>false</EnableQuarantineChecks>
<RequireCryptoBinding>true</RequireCryptoBinding>
<PeapExtensions>
<PerformServerValidation xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">true</PerformServerValidation>
<AcceptServerName xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">false</AcceptServerName>
</PeapExtensions>
</EapType>
</Eap>
</Config>
</EapHostConfig>
</Configuration>
</Eap>
</Authentication>
<!--Sample routing policy: in this case, this is a split tunnel configuration with two routes configured-->
<RoutingPolicyType>SplitTunnel</RoutingPolicyType>
<DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
</NativeProfile>
<Route>
<Address>192.168.0.0</Address>
<PrefixSize>24</PrefixSize>
</Route>
<Route>
<Address>10.10.0.0</Address>
<PrefixSize>16</PrefixSize>
</Route>
<!--VPN will be triggered for the two apps specified here-->
<AppTrigger>
<App>
<Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
</App>
</AppTrigger>
<AppTrigger>
<App>
<Id>C:\windows\system32\ping.exe</Id>
</App>
</AppTrigger>
<!--Example of per-app VPN. This configures traffic filtering rules for two apps. Internet Explorer is configured for force tunnel, meaning that all traffic allowed through this app must go over VPN. Microsoft Edge is configured as split tunnel, so whether data goes over VPN or the physical interface is dictated by the routing configuration.-->
<TrafficFilter>
<App>
<Id>%ProgramFiles%\Internet Explorer\iexplore.exe</Id>
</App>
<Protocol>6</Protocol>
<LocalPortRanges>10,20-50,100-200</LocalPortRanges>
<RemotePortRanges>20-50,100-200,300</RemotePortRanges>
<RemoteAddressRanges>30.30.0.0/16,10.10.10.10-20.20.20.20</RemoteAddressRanges>
<RoutingPolicyType>ForceTunnel</RoutingPolicyType>
</TrafficFilter>
<TrafficFilter>
<App>
<Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
</App>
<LocalAddressRanges>3.3.3.3/32,1.1.1.1-2.2.2.2</LocalAddressRanges>
</TrafficFilter>
<!--Name resolution configuration. The AutoTrigger node configures name-based triggering. In this profile, the domain "hrsite.corporate.contoso.com" triggers VPN.-->
<DomainNameInformation>
<DomainName>hrsite.corporate.contoso.com</DomainName>
<DnsServers>1.2.3.4,5.6.7.8</DnsServers>
<WebProxyServers>5.5.5.5</WebProxyServers>
<AutoTrigger>true</AutoTrigger>
</DomainNameInformation>
<DomainNameInformation>
<DomainName>.corp.contoso.com</DomainName>
<DnsServers>10.10.10.10,20.20.20.20</DnsServers>
<WebProxyServers>100.100.100.100</WebProxyServers>
</DomainNameInformation>
<!--EDPMode is turned on for the enterprise ID "corp.contoso.com". When a user accesses an app with that ID, VPN will be triggered.-->
<EdpModeId>corp.contoso.com</EdpModeId>
<RememberCredentials>true</RememberCredentials>
<!--Always On is turned off, and triggering VPN for the apps and domain name specified earlier in the profile will not occur if the user is connected to the trusted network "contoso.com".-->
<AlwaysOn>false</AlwaysOn>
<DnsSuffix>corp.contoso.com</DnsSuffix>
<TrustedNetworkDetection>contoso.com</TrustedNetworkDetection>
<Proxy>
<Manual>
<Server>HelloServer</Server>
</Manual>
<AutoConfigUrl>Helloworld.Com</AutoConfigUrl>
</Proxy>
<!--Device compliance is enabled and an alternate certificate is specified for domain resource authentication.-->
<DeviceCompliance>
<Enabled>true</Enabled>
<Sso>
<Enabled>true</Enabled>
<Eku>This is my Eku</Eku>
<IssuerHash>This is my issuer hash</IssuerHash>
</Sso>
</DeviceCompliance>
</VPNProfile>
```
## Sample plug-in VPN profile
The following sample is a sample plug-in VPN profile. This blob would fall under the ProfileXML node.
```xml
<VPNProfile>
<ProfileName>TestVpnProfile</ProfileName>
<PluginProfile>
<ServerUrlList>testserver1.contoso.com;testserver2.contoso..com</ServerUrlList>
<PluginPackageFamilyName>JuniperNetworks.JunosPulseVpn_cw5n1h2txyewy</PluginPackageFamilyName>
<CustomConfiguration>&lt;pulse-schema&gt;&lt;isSingleSignOnCredential&gt;true&lt;/isSingleSignOnCredential&gt;&lt;/pulse-schema&gt;</CustomConfiguration>
</PluginProfile>
<Route>
<Address>192.168.0.0</Address>
<PrefixSize>24</PrefixSize>
</Route>
<Route>
<Address>10.10.0.0</Address>
<PrefixSize>16</PrefixSize>
</Route>
<AppTrigger>
<App>
<Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
</App>
</AppTrigger>
<AppTrigger>
<App>
<Id>%ProgramFiles%\Internet Explorer\iexplore.exe</Id>
</App>
</AppTrigger>
<TrafficFilter>
<App>
<Id>%ProgramFiles%\Internet Explorer\iexplore.exe</Id>
</App>
<Protocol>6</Protocol>
<LocalPortRanges>10,20-50,100-200</LocalPortRanges>
<RemotePortRanges>20-50,100-200,300</RemotePortRanges>
<RemoteAddressRanges>30.30.0.0/16,10.10.10.10-20.20.20.20</RemoteAddressRanges>
<!--<RoutingPolicyType>ForceTunnel</RoutingPolicyType>-->
</TrafficFilter>
<TrafficFilter>
<App>
<Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
</App>
<LocalAddressRanges>3.3.3.3/32,1.1.1.1-2.2.2.2</LocalAddressRanges>
</TrafficFilter>
<TrafficFilter>
<App>
<Id>Microsoft.MicrosoftEdge_8wekyb3d8bbwe</Id>
</App>
<Claims>O:SYG:SYD:(A;;CC;;;AU)</Claims>
<!--<RoutingPolicyType>SplitTunnel</RoutingPolicyType>-->
</TrafficFilter>
<DomainNameInformation>
<DomainName>corp.contoso.com</DomainName>
<DnsServers>1.2.3.4,5.6.7.8</DnsServers>
<WebProxyServers>5.5.5.5</WebProxyServers>
<AutoTrigger>false</AutoTrigger>
</DomainNameInformation>
<DomainNameInformation>
<DomainName>corp.contoso.com</DomainName>
<DnsServers>10.10.10.10,20.20.20.20</DnsServers>
<WebProxyServers>100.100.100.100</WebProxyServers>
</DomainNameInformation>
<!--<EdpModeId>corp.contoso.com</EdpModeId>-->
<RememberCredentials>true</RememberCredentials>
<AlwaysOn>false</AlwaysOn>
<DnsSuffix>corp.contoso.com</DnsSuffix>
<TrustedNetworkDetection>contoso.com,test.corp.contoso.com</TrustedNetworkDetection>
<Proxy>
<Manual>
<Server>HelloServer</Server>
</Manual>
<AutoConfigUrl>Helloworld.Com</AutoConfigUrl>
</Proxy>
</VPNProfile>
```
## Apply ProfileXML using Intune
After you configure the settings that you want using ProfileXML, you can create a custom profile in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). After it's created, you deploy this profile to your devices.
1. Sign in to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Select **Devices** > **Configuration profiles** > **Create profile**.
3. Enter the following properties:
- **Platform**: Select **Windows 10 and later**
- **Profile**: Select **Templates** > **Custom**.
4. Select **Create**.
5. In **Basics**, enter the following properties:
- **Name**: Enter a descriptive name for the profile. Name your profiles so you can easily identify them later.
- **Description**: Enter a description for the profile. This setting is optional, but recommended.
6. Select **Next**.
7. In **Configuration settings**, enter the following properties:
- **OMA-URI**: Enter `./user/vendor/MSFT/VPNv2/Your_VPN profile name_/ProfileXML`.
- **Data type**: Select `String (XML file)`.
- **Value**: Browse to, and select your XML file.
For more information on these settings, see [Use custom settings for Windows devices in Intune](/mem/intune/configuration/custom-settings-windows-10).
8. Select **Next**, and continue configuring the policy. For the specific steps and recommendations, see [Create a profile with custom settings in Intune](/mem/intune/configuration/custom-settings-configure).
## Learn more
- [Create VPN profiles to connect to VPN servers in Intune](/mem/intune/configuration/vpn-settings-configure)
- [VPNv2 configuration service provider (CSP) reference](/windows/client-management/mdm/vpnv2-csp)
- [How to Create VPN Profiles in Configuration Manager](/previous-versions/system-center/system-center-2012-R2/dn261200(v=technet.10))
## Related articles
- [VPN technical guide](vpn-guide.md)
- [VPN connection types](vpn-connection-type.md)
- [VPN routing decisions](vpn-routing.md)
- [VPN authentication options](vpn-authentication.md)
- [VPN and conditional access](vpn-conditional-access.md)
- [VPN name resolution](vpn-name-resolution.md)
- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
- [VPN security features](vpn-security-features.md)

View File

@ -0,0 +1,55 @@
---
ms.date: 05/24/2023
title: VPN routing decisions
description: Learn about approaches that either send all data through a VPN or only selected data. The one you choose impacts capacity planning and security expectations.
ms.topic: conceptual
---
# VPN routing decisions
Network routes are required for the stack to understand which interface to use for outbound traffic. One of the most important decision points for VPN configuration is whether you want to send all the data through VPN (*force tunnel*) or only some data through the VPN (*split tunnel*). The decision impacts the configuration, capacity planning, and security expectations from the connection.
## Split tunnel configuration
In a split tunnel configuration, routes can be specified to go over VPN and all other traffic will go over the physical interface.
Routes can be configured using the `VPNv2/<ProfileName>/RouteList` setting in the [VPNv2 Configuration Service Provider (CSP)](/windows/client-management/mdm/vpnv2-csp).
For each route item in the list, you can configure the following options:
- **Address**: `VPNv2/<ProfileName>/RouteList/<routeRowId>/Address`
- **Prefix size**: `VPNv2/<ProfileName>/RouteList/<routeRowId>/Prefix`
- **Exclusion route**: V`VPNv2/<ProfileName>/RouteList/<routeRowId>/ExclusionRoute`
With Windows VPN, you can specify exclusion routes that shouldn't go over the physical interface.
Routes can also be added at connect time through the server for UWP VPN apps.
## Force tunnel configuration
In a force tunnel configuration, all traffic will go over VPN. Force tunnel is the default configuration, and takes effect when no routes are specified.
The only implication of force tunnel is the manipulation of routing entries: VPN V4 and V6 default routes (for example *0.0.0.0/0*) are added to the routing table with a lower metric than ones for other interfaces. This configuration sends traffic through the VPN as long as there isn't a specific route on the physical interface:
- For built-in VPN, the decision is controlled using the MDM setting `VPNv2/ProfileName/NativeProfile/RoutingPolicyType`
- For a UWP VPN plug-in, the app controls the property. If the VPN plug-in indicates the default route for IPv4 and IPv6 as the only two Inclusion routes, the VPN platform marks the connection as Force Tunneled
## Configure routing
See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
When you configure a VPN profile in Microsoft Intune, you can enable split tunnel configuration:
![split tunnel.](images/vpn-split.png)
Once enabled, you can add the routes that should use the VPN connection.
## Related articles
- [VPN technical guide](vpn-guide.md)
- [VPN connection types](vpn-connection-type.md)
- [VPN authentication options](vpn-authentication.md)
- [VPN and conditional access](vpn-conditional-access.md)
- [VPN name resolution](vpn-name-resolution.md)
- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
- [VPN security features](vpn-security-features.md)
- [VPN profile options](vpn-profile-options.md)

View File

@ -0,0 +1,68 @@
---
title: VPN security features
description: Learn about security features for VPN, including LockDown VPN and traffic filters.
ms.date: 05/24/2023
ms.topic: conceptual
---
# VPN security features
## Hyper-V based containers and VPN
Windows supports different kinds of Hyper-V based containers, like Microsoft Defender Application Guard and Windows Sandbox. When you use a third party VPN solution, the Hyper-V based containers may not be able to seamlessly connect to the internet, and configuration changes may be needed to resolve connectivity issues.
For example, read about the workaround for Cisco AnyConnect VPN: [Cisco AnyConnect Secure Mobility Client Administrator Guide: Connectivity issues with VM-based subsystems](https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect410/administration/guide/b-anyconnect-admin-guide-4-10/troubleshoot-anyconnect.html#Cisco_Task_in_List_GUI.dita_3a9a8101-f034-4e9b-b24a-486ee47b5e9f).
## Traffic Filters
Traffic Filters enables organizations to decide what traffic is allowed into the corporate network based on policy. IT admins can use Traffic Filters to apply interface-specific firewall rules to the VPN Interface.
There are two types of Traffic Filter rules:
- **App-based rules** consist of a list of applications that can be marked to only allow traffic originating from the apps to the VPN interface
- **Traffic-based rules** consist of 5-tuple policies (ports, addresses, protocol) that can be specified to only allow traffic matching the rules to go through the VPN interface
There can be sets of rules linked by *OR*. Within each set, there can be app-based rules and traffic-based rules.\
All the properties within the set are linked by *AND*. The rules can be applied at a per-app level or a per-device level.
For example, an IT admin could define rules that specify:
- An *HR App* is allowed to go through the VPN and only access port *4545*
- The *Finance apps* are allowed to through the VPN and only access the Remote IP ranges of *10.10.0.40 - 10.10.0.201* on port *5889*
- All other apps on the device can only access ports *80* or *443*
## Configure traffic filters
See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
The following image shows the interface to configure traffic rules in a VPN Profile configuration policy, using Microsoft Intune.
:::image type="content" source="images/vpn-traffic-rules.png" alt-text="VPN profile creation from Microsoft Intune admin center." lightbox="images/vpn-traffic-rules.png":::
## LockDown VPN
A VPN profile configured with LockDown secures the device to only allow network traffic over the VPN interface. It has the following features:
- The system attempts to always keep the VPN connected
- The user can't disconnect the VPN connection
- The user can't delete or modify the VPN profile
- The VPN LockDown profile uses forced tunnel connection
- If the VPN connection isn't available, outbound network traffic is blocked
- Only one VPN LockDown profile is allowed on a device
> [!NOTE]
> For built-in VPN, LockDown VPN is only available for the Internet Key Exchange version 2 (IKEv2) connection type.
> [!CAUTION]
> Be careful when deploying LockDown VPN, as the resultant connection won't be able to send or receive any network traffic without the VPN connection being established.
## Related articles
- [VPN technical guide](vpn-guide.md)
- [VPN connection types](vpn-connection-type.md)
- [VPN routing decisions](vpn-routing.md)
- [VPN authentication options](vpn-authentication.md)
- [VPN and conditional access](vpn-conditional-access.md)
- [VPN name resolution](vpn-name-resolution.md)
- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
- [VPN profile options](vpn-profile-options.md)