Always On VPN Device Tunnel with Windows 10 1709

Always On VPN Device Tunnel with Windows 10 1709

Always On VPN Device Tunnel with Windows 10 1709

Update 22/11/2017: Microsoft’s official guidance on Device Tunnel configuration is now available at https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config

A long awaited feature with the DirectAccess successor Always On VPN (Auto VPN) is the ability for clients to initiate an infrastructure tunnel to the corporate network without the user logging on. This feature named Device Pre-Logon is available in Windows 10 1709 update.

Over the last several years Microsoft’s VPN or remote connectivity solution has primarily been DirectAccess. Whilst DirectAccess provided seamless always on remote connectivity, it did however come with a few drawbacks. Originally released with Server 2008 it only supported IPv6 and utilised UAG. With Server 2012, 2012R2 Microsoft removed the need to utilise UAG and streamlined the installation and configuration. Still available in Server 2016 DirectAccess is not a technology that is obsolete but far from it with many organisation using it to provide users with remote connectivity. Once configured DIrectAccess…just works. For at least the short term DirectAccess is proven to be reliable and the remote connectivity solution of choice, as long as you can overcome single stack IPv6,  but if you want the latest and greatest then Always On VPN is the future.

However DirectAccess is a dark art and the solution can be difficult to install and configure to the novice professional. Always On VPN on the other hand has all the missing features and more that DirectAccess should have had. This not to to be taken lightly, as Always On VPN is also not a walk in the park to implement, away with the GUI, Always On VPN utilises configuration service provider (CSP’s) in order for implementation.

Always On VPN is the new kid on the block, released in Windows 10, the major benefit of a Device Pre-Logon tunnel has been released with 1709 Creators Update for Windows 10. This allows administrators to always have the ability to manage Windows 10 devices once they leave the corporate environment. When a device is connected to a known network, it will automatically initiate a VPN connection back to corporate environment where it can be managed. For example this can group policies, windows update or even configmgr.

The official statement from Microsoft is to deploy Always On VPN instead of DirectAccess, but many organisations would be very reluctant to deploy a solution which has just arrived on the market. The below outlines the benefits and drawbacks of DirectAccess:

DirectAccess

Benefits:

  1. Always On
  2. Seamless
  3. Infrastructure Tunnel for device management in addition to the User Tunnel
  4. Built into Windows 10 no additional clients needed
  5. Uses IPHTTPS tunneling protocol
  6. GUI for easy configuration
  7. Still supported and available in Server 2016

Drawbacks

  1. IPv6 only solution. Applications installed on the client must support IPv6, certain exception are made for example Office Communication Server 2007 does not work with DirectAccess
  2. No granular control
  3. Manage-Out not supported when more than 1 DirectAccess server is present in a configuration ( although it is possible to get Manage-Out working with multiple servers using a solution by Richard Hick’s)
  4. Limited access to End to End encryption to application servers
  5. No support for VPN gateways
  6. NAT64, DNS64 componets are utilised to transverse IPv6 to IPv4
  7. Teredo and 6to4 are not supported behind a NAT/Firewall
  8. Only Windows Domain joined devices are supported
  9. Network Access Protection deprecated in 2012R2

 

Always On VPN

Benefits:

  1. Uses industry standard IKEv2 tunneling protocol with the ability to fall back to SSTP when behind firewalls or proxy’s
  2. Dual stack support for IPv4 and IPv6
  3. Granular control for End to End encryption to application servers using policies
  4. Granular control over routing, specifically control routing behavior to define which traffic should only ever traverse the VPN and not go over the physical network interface
  5. Name based triggering allow specific domain name queries to trigger the VPN
  6. Application Triggering, when specified desktop and/or universal windows apps are, the VPN will automatically trigger
  7. Supports VPN gateways behind a NAT or edge device in addition Remote Access servers can be used
  8. No requirement for Active Directory or Windows domain joined devices, nor a requirement on an Enterprise version of Windows 10
  9. Application specific routing is supported (Managed tunnel)
  10. No requirement for Network Location Servers in order to determine if a client is within the corporate boundary or outside. Trusted Network Assessment is ustilised which assesses  the connection-specific DNS suffix assigned to network interfaces
  11. Ability to integrate with Azure Conditional Access Platform to enforce Device Compliance and/or multi-factor authentication
    1. Multi-factor authentication includes the ability to use Windows Hello for Business Certificate
  12. Support of RSA and ECC to meet specific cryptography requirements such as those set by the National Cyber Security Centre in the United Kingdom or other government/corporate organisations.

Drawbacks

  1. Can be difficult to configure using PowerShell, Intune, ConfigMgr or Windows Configuration Designer have to be used to configure Always On VPN
  2. Remediation’s or quarantining is not supported using Azure Conditional Access Platform
  3. New kid on the block and may require maturing, potential to have unknown bugs

 

Attachments

33 Replies to “Always On VPN Device Tunnel with Windows 10 1709”

  1. Documentation ragarding the new futures (device tunnels) are no where to be found, most are only focust on user based. Any advise?

  2. Hi Kam,

    I am struggling to use the DeviceTunnel seting, even though I set it true in my ProfileXML when I create the VPN running powershell as the system user it returns;

    ParentID : ./Vendor/MSFT/VPNv2

    ProfileXML : truetruefalse

    Are there any prerequisites for the DeviceTunnel setting?

    Thanks

    Dan

  3. That middle bit didn’t post properly, here is is again as i am unable to edit my post.

    ParentID : ./Vendor/MSFT/VPNv2

    ProfileXML : “truetruefalse”

    1. Hi Dan,
      Unfortunately there is not true guidance from MS on configuring the device tunnel. The deployment guide currently provided for AlwaysOn VPN is based on the User tunnel and authenticates using a User certificate. The issue is if you add the true parameter to the profile XML provided by MS, the tunnel will not initiate/work. This is because the PowerShell script provided by MS is user based and not computer based. In order to initiate a Device Tunnel you would need to issue a computer certificate and configure RRAS to authenticate IKEv2 Machine certificates, although this does work (if you create the VPN profile manually on the Windows 10 1709 machine) it is NOT AlwaysOn and will not initiate automatically and if you try to create a VPN profile using this method it will fail. I am waiting upon further guidance and clarification from MS regarding this.

      The AlwaysOn Windows 10 documentation I am referring to is https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections

      Thanks
      Kam

    2. Hi Dan,

      After some tweaking and a reply from MS I have managed to get the Device Tunnel working, please use this as testing until MS release guidance. Please Note the below:
      1. You cannot see the VPN connection when clicking on the network icon on the taskbar. You have to go into Control Pannel > Network Connections.
      2. You will need to issue a computer certificate for IKEv2 authentication.
      3. Your RRAS server must have Machine Certificate authentication enabled.
      4. Once you run the script it will create a VPN connection, however you must delete this connection before re-running the script. I have added a smaller script for removing the VPN connection.

      Steps:
      1. Issue a computer certificate to the Windows 10 1709 machine ( the certificate should be similar to the user certificate that MS deployments suggests HERE but you should of course use the Computer certificate template.
      2. Run the script, although this will create your device tunnel you will need to head into Control Panel> Network Connections to see the VPN entity that you just created, the VPN connection does not show when you click the network icon on the taskbar!.

      I have attached the script to this post

  4. Thanks for the script. Hopefully microsoft enable the ability to view the vpn connection in the networks pane.

  5. Hopefully Mike!!, a User must be able to easily identify when he/she is connected to the corporate network. I will keep you posted if I hear anything.

  6. Hi Kam
    We have tried this afternoon, but we’re still getting false in the results of ProfileXML
    The connection doesn’t show in VPNs but does under Network Connections. It’s like it’s stuck between user and device.
    We’re waiting to hear from MS, but wonder if you have any ideas?
    Thanks

  7. Hi Stephen,

    How are you deploying the VPNv2 settings? Have you tried the script within this post?

    Can you share your ProfileXML? (remove any private data from your ProfileXML before sharing.

    Thanks
    Kam

  8. Hi Kam
    I took your script and inserted our domain, IPs and so on. No matter what ID I run it under (domain admin, local admin, SYSTEM), it comes up with false for the DeviceTunnel tag in Profile.xml parameter.

    To make matters stranger still, it does try to dial it, I get a RasClient cert error message (event 13801) in the local event log, but nothing (not denied, failed, etc.) on the RRAS or Radius end.
    Cheers
    Stephen

  9. Hi Stephen,
    I can confirm that the device tunnel tag does returns false, but the tunnel should initiate regardless. Have you installed the computer certificate and enabled Machine Certificate Authentication on your RRAS server?

    To enable Machine Certificate Authentication:
    Open RRAS console
    Right click the server > click Properties >click Security > click Authentication Methods > Select “Allow machine certificate authentication for IKEv2”
    Reboot RRAS server

    Thanks
    Kam

  10. Slowly winning 🙂
    That was missing, but once ticked the laptop happily connects (to either of the RRAS servers). I can logon then with a user that has never used the laptop, but pretty much as soon as the desktop appears, we lose the VPN connection. Makes no difference if the user has a VPN cert or not.

  11. And this is interesting. Flipping between two WiFi networks, and the laptop is registering the WiFi IP in DNS rather than the VPN one

  12. Ignore the DNS registration, we’d somehow managed to lose the RegisterDNS option, so that’s now working (registers both the VPN and WiFi or Mobile network ones)
    The VPN connection was created as SYSTEM
    Frustratingly close to getting this working

  13. Hi Stephen, I am seeing the same issue after running through the same steps, when a new user logs onto the device the vpn tunnel is disconnected. I’ll keep on looking into this.

  14. Hi Kam,

    Any progress with the device tunnels? I’ve been testing myself and while I can get a tunnel up easily the Device rather than User side as well as the auto/always ok portion mostly don’t work.

  15. We have this working, at least so far.

    Under Local Admin profile (admin/support)
    Run a user VPN_Profile.ps1 (as created via the Microsoft step-through article)
    This creates a user AutoVPN connection that is not used but exists, which appears to be the key. I used the local admin profile, but any user will actually do. The only issue encountered so far with that is that when the laptop hibernates then brought back to life, both VPNs connect.

    Create a Device VPN connection as NT AUTHORITY\SYSTEM
    This can be done manually as follows, but we’re looking to get it into our SCCM build
    Open Command Prompt as Administrator
    psexec -i -s powershell.exe
    VPN_Profile.ps1

    Device PowerShell, basically a copy of Kam’s except we’re using
    ForceTunnel

  16. Just to clarify, the User AutoVPN only connects for the user when logged in, which is why I used local admin. The two connections only happen if you have it in the active user. You could create a “pretend” user that is not used.

  17. What happens if, once created, you run the vpn_profile.ps1 on a clean client? Only the computer should be created..

  18. You need to run both scripts. What I did over the last couple of days:
    1. Build new laptop (which gets an auto-enroll cert for authentication)
    2. Logon with my domain admin ID and create Device VPN connection as NT AUTHORITY\SYSTEM (using the psexec method). Logoff
    3. Logon as laptop’s local admin ID and create User VPN connection. Logoff. At this point you could use your pretend user, it just needs an ID with the user profile in it on the system.
    4. Disconnect laptop from LAN. Laptop connects to Mobile or Wi-Fi, the Device Tunnel kicks in, and connection can be seen on RRAS box
    5. Logon with a standard user that has never used laptop before via the VPN

  19. When you say “You need to run both scripts.”, do you mean the exact same tunnel PS1 creation script needs to be ran as User and as SYSTEM? Or is there a different script I’m not seeing? If the same script needs to be ran 2x, any idea why? Any ideas why just SYSTEM is not enough, especially since the User side is specifically an account you would never actually use as you say?

    I’ve tried running Kam’s script that he attached as SYSTEM via the psexec method and I always get a “generic error” and the VPN interface is not created. I have no issues running it as the admin user, including the weird behavior of the device tunnel parameter causing the connection to be not visible in the network icon in the task bar, so that part is “working” like everyone else seems to be seeing. I’ve also had lots of issues getting the AlwaysOn flag to work correctly, it shows as enabled but it does not trigger a connection logged in as a user. I have no problems getting the VPN to connect when I manually try to establish a connection so the actual parameters of the connection seem to be ok.

    Would you mind posting a link of your version of the script and XM with the private parts replaced of course? I’m using a PS1 file with the XML string inside rather than a separate file, could that be the issue? I’d like to review/test with your working setup? And again just to 100% verify, the script and XML tunnel info that is running as Admin as well as SYSTEM is the exact same file?

  20. Hi,

    The official documentation will be released hopefully within the next 2 weeks, the documentation is currently being reviewed internally by Microsoft. Probably best to wait until then before you implement anything in production.

    Thanks
    Kam

  21. Hey,

    We are only having the device tunnel enabled (no user profile).

    Everything works alright, until we reboot the device after we have applied the VPN profile. Then it stop working!

    Nothing shows in the logs, besides it actually says the profile was successful connected. But in “Network Connections” it’s stuck in connecting state and the machine doesn’t get any IP.

    I can force the connection and get it to work if I first disconnect, and then reconnect again using the following in a command prompt:

    rasdial.exe “” /disconnect

    rasdial.exe “”

    We are using the sample XML file (with relevant connection details substituted) found here:

    https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config#configure-the-vpn-device-tunnel

    The profile was made in the “SYSTEM” context.

    Any ideas guys, I appreciated if someone have a solution!

    Kind Regards Alex

  22. Great post Kam! This has really helped progress our testing and knowledge of AOV.

    Just out of curiosity, has anyone managed to get both Device and User tunnels to work in harmony together? If so, what is the expected behaviour? Does the Device tunnel drop when the User tunnel is active, or do both tunnels remain active together.

    Thanks
    Nick

  23. Same issue here. MS case registered, they have been scratching their heads for a couple of weeks now.

  24. Hello,
    I try to configure SSTP as a fallback for IKEv2. When I use “Automatic” as NativeProtocolType, the connection is failed. 🙁
    Any ideas ?
    Thanks !
    Marko

  25. Hi Kam

    I use your script DeviceTunnelWMI to create tunnelDevice on LocalSystem (psexec). The tunnel is not connected pre logon.

    did I forget a manipulation ?

    This detail:

    $servers= “externe.mylab.local”
    $dnssuffix=’labo.local’
    $DomainName=’.labo.local’
    $DNSservers=’192.168.100.1′
    $TrustedNetwork=’labo.local’
    $ProfileName=”AlwaysOnDevice’

    …….

    xml

    “externe.mylab.local”

    I completed suffix DNS on stack IP (Local network): mylab.local, labo.local.

    I install certificate machine on client (Authentication client, authentication server).

    I tried create connection VPN manually based certificate machine, and connection VPN works.

    Do you have an idea ?

    My licence Windows 10 Entreprise 1709 is not activate.

    Thank you

    Patrick

    1. Hi Patrick, there have been some fixes in Windows 1803. I will hopefully get an update guide out on a step by step configuration.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: