Always On VPN Bug in Windows 10 2004

Always On VPN Bug in Windows 10 2004While performing Always On VPN evaluation testing with the latest release of Windows 10 (2004), a bug was discovered that may result in failed VPN connections, but only under certain conditions. Specifically, the failure occurs when both the device tunnel and user tunnel are configured on the same client, and the user tunnel is configured to use IKEv2 exclusively.

Error 829

After upgrading to Windows 10 2004, and when the device tunnel and user tunnel are both deployed and the user tunnel is configured to use IKEv2, the administrator will notice that if the device tunnel connection is established, the user tunnel connects successfully but is then terminated abruptly with error code 829.

Always On VPN Bug in Windows 10 2004

Note: This can happen in reverse if the user tunnel is established before the device tunnel for some reason. In this scenario the user tunnel would be connected but attempts to establish the device tunnel would result in failure.

Error 619

If the user tunnel connection is initiated using rasdial.exe or rasphone.exe, the error code returned is 619.

Always On VPN Bug in Windows 10 2004

Always On VPN Bug in Windows 10 2004

Workaround

The workaround for this issue is to either use a single tunnel, or if both user tunnel and device tunnel are required, configure the user tunnel to use the SSTP VPN protocol instead of IKEv2.

Additional Information

Windows 10 Always On VPN Device Tunnel Only Deployment Considerations

Leave a comment

45 Comments

  1. Here’s hoping they fix this soon!

    Reply
    • For sure! It won’t affect everyone as most are using SSTP for the user tunnel in my experience. However, for those looking for the highest level of security, using IKEv2 is a requirement. They’ll definitely be affected.

      Reply
  2. Simon

     /  June 25, 2020

    *sigh* one more nail in the coffin for IKEv2 🙁

    Reply
  3. Matt

     /  June 25, 2020

    Wow!
    Windows 10 2004 has so many bugs despite having extended testing due to the release postponements.
    I guess nobody tested AOVPN very much during Windows Insider release rings because it’s not as if it takes an extremely obscure configuration to expose this obvious issue.

    Does 2004 have any AOVPN improvements over earlier releases?

    Reply
    • It’s a pretty obvious bug, so one would have to guess as to how reliable the testing process is. 😉 I’m hearing that Always On VPN in Windows 10 2004 now supports manage out with traffic filters, but I’ve not seen any formal documentation on that yet.

      Reply
  4. Chris Podurgiel

     /  June 28, 2020

    We’ve been experiencing similar symptoms on 1909. I’m wondering if a recent update that shares code with 2004 is to blame.

    Reply
    • Anything is possible. In my testing this only seemed to affect 2004 devices though. Hopefully Microsoft issues some guidance and ideally a fix soon. 🙂

      Reply
  5. Julien Potier

     /  June 30, 2020

    I’m experiencing something very similar on W10 1803. Device VPN terminates randomly with reason code 828 (timeout) which is not configured on the device VPN side. We force the use of IKEv2 since SSTP is terrible for real time traffic. I need to investigate further

    Reply
    • I’d be curious to know if you are having this same issue on 1903/1909. Earlier versions of Windows 10 are always suspect IMO.

      Reply
  6. Drew

     /  July 2, 2020

    I’m seeing something similar on 2004, but my User tunnel is set to Auto (using the XML config from your blog, thank you!) and it connects as SSTP while my Device tunnel is obviously IKEV2. My user tunnel doesn’t SEEM to be affected but my device tunnel seems to randomly disconnect. If i attempt to dial the device connection via psexec RasDial.exe i get error 619 and i also get error 829 in the Application event log. I’ll see if hard coding the user tunnel to SSTP helps.

    Reply
  7. Victor Musatov

     /  July 9, 2020

    I confirm, Windows 10 2004, user sstp tunnel, device ikev2 tunnel, after waking up, only the user tunnel will automatically connect, devicetunnel ends with error 619/829

    Reply
  8. I confirm, Windows 10 2004, user sstp tunnel, device ikev2 tunnel, after waking up, only the user tunnel will automatically connect, devicetunnel ends with error 619/829

    Reply
  9. SebC

     /  July 18, 2020

    For 2004 i did 2 Tasks and one PS-Script, when User logs in the script will trigger first Task and will end with system-account (rasdial.exe /d) the Device Tunnel, after that the 2nd Task will trigger with Logged-In User with the IKEV2 user Tunnel, works perfect as workaround. Best to do with do-while loop for each tunnel, but still hoping MS will fix it soon for 2004, sadly with the July Update they did not 🙁

    Reply
  10. After doing an in-place upgrade from 1803 to 2004 I am seeing this error consistently (619). The only difference is that the user tunnel is set to SSTP, not IKEv2.This is so disappointing.

    Reply
    • Interesting. In my testing it only happened when IKEv2 was used on the user tunnel. If I switch to SSTP it works. Not your experience?

      Reply
      • Richard, both tunnels work concurrently only if I:

        1. Turn off the User tunnel auto-connect
        2. Connect the Device tunnel
        3. Turn back on the User tunnel auto-connect

        I’ve only seen this in two cases so far – but one of them is my laptop – and that’s why I’m cross 🙂
        I’ll continue to see if there a pattern as my company rolls out the 2004 update. In the worst case we’ll just have to live without the device tunnel.

  11. I have reported this on Windows Feedback Hub today, as a high-priority bug. Please upvote! 🙂

    “Manual VPN prompts for password, and Always-On VPN broken in 2004”

    “We are seeing these two bugs on all PC’s in our domain (hundreds) – both those upgraded from 1909 to 2004, and those with a fresh install of 2004. It was OK before 2004.

    1) Native Windows manual VPN which have the option “Automatically use my Windows logon name and password (and domain, if any)” enabled, fails. When using “Connect” at the VPN it replies “The user name or password is incorrect”, instead of just connecting the VPN. It prompts for a password, and when correct password is entered, the VPN connects.

    2) Native Windows Always-On user VPN fails to connect automatically. Instead it asks for a password, just like the bug above. So the Always-On feature is broken.

    Which workaround exists?”

    Reply
    • Can you share the link? Happy to up-vote it for you! 🙂 I’m assuming then you are using MS-CHAP v2 authentication, correct? That’s not something I’ve tested on 2004 as I typically use PEAP and client certificate authentication. Happy to test and see if I can reproduce though.

      Reply
      • Thanks for reminding me that I forgot the link – here it is:
        https://aka.ms/AA93bvb

        For the manual VPN we are using:
        Type of VPN = Automatic
        Authentication = Allow these protocols: MS-CHAP v2 / Automatically use my Windows logon

        The reason for “Automatic” is that we have employees and consultants working for us from all the world, some very far away (RTT 300+ ms) and some in highly Internet censured countries. IKEv2 is chosen as the primary protocol as it gives a several factors higher throughput for TCP traffic than SSTP when the RTT is very high. SSTP is then the fallback protocol used where IKEv2 is blocked, as it works everywhere.

        Authentication for the manual VPN is not based on client certificates as we find it would be too complicated to distribute and handle for the many external consultants who are employed in other companies, and works for us for a limited time. Instead, we limit their of access in AD, so their access is blocked after their contract period.

        When I made our Always-On user profile in the beginning of 2019, it was my intention to make it certificate based, as it is only relevant for employees and not for external consultants. However, when I review my code now, it seems I missed that when I ran the Makeprofile script. I will give it a try and change it to certificate based, it will probably be a workaround for the Always-On VPN problem.

        But the manual VPN still has a problem using the cached Windows logon.

    • Matt Tasker

       /  July 30, 2020
      Reply
  12. We see a difference regarding the random password mentioned in the Technet article; I have described it in a comment to the Technet article.

    Reply
  13. Ed

     /  August 4, 2020

    Incredibly frustrating that this is still broken. Not fixed in KB4568831. Is everyone at Microsoft asleep? Surely always on vpn is a priority at the moment?

    Reply
  14. Luke Flack

     /  August 6, 2020

    Hi Richard,

    I’m seeing this 829 error on 1709 as well. I have IKEv2 for both tunnels coexisting together, with SSTP fallback on the User Tunnel. However it never falls back to SSTP because it does successfully connect on IKEv2.
    I find that the User Tunnel and Device Tunnels both seem to oscillate back and forth, each one disconnecting the other tunnel with termination code 829 for both. As soon as I set the User Tunnel to SSTP only everything works fine.
    Do we know if there are any other workarounds for this?
    I don’t want to loose IKEv2 for the User Tunnel if at all possible.

    Thanks,
    Luke

    Reply
    • I believe this specific bug only occurs with Windows 10 2004, but there could certainly be other issues causing these same symptoms. I’m not aware of any workarounds at the moment either.

      Reply
  15. Hello,
    had a chat to MS today, they stated this will be hopefully fixed in next months patches.

    Reply
    • I’m hearing the same thing. Hope to see this in the next month or so. I’ll be sure to update the post as soon as it is released and tested. 🙂

      Reply
      • Colin

         /  August 24, 2020

        Rich,

        My experience with this is that if the user tunnel is configured for automatic, the device tunnel wont come up. If I set the user tunnel to SSTP and let the device tunnel connect, then I can connect the user tunnel.

        This leads me to think that the device tunnel naturally comes up first anyway after a restart/power on and the user tunnel should work after that.

        I really hope they fix this soon! Not cool with the amount of remote workers at the moment.

        P.S. They used to have a little purple blurb about manage out coming to device tunnels with traffic filters enabled… I think they removed it.. any word on this on your end?

      • I’m hearing that manage out with traffic filters enabled has been fixed, but requires additional configuration. However, Microsoft hasn’t published documentation for that yet. I’ll put something out soon when it is available.

  16. iainse

     /  September 2, 2020

    I have hit this issue with a customer and found a work-around. On the VPN server create a certificate with two DNS (SAN) names. AOVPN.customer.com and AOVPN2.customer.com. On one tunnel use AOVPN.customer.com and the other AOVPN2.customer.com.

    Reply
  17. Ian Clegg

     /  September 4, 2020

    Hi Rich, some interesting fixes mentioned in the September windows 10 2004 hotfix release:

    Addresses an issue that prevents Always On VPN (AOVPN) from automatically reconnecting when resuming from Sleep or Hibernate.

    Addresses an issue that causes AOVPN user tunnels to use an incorrect certificate.

    Addresses an issue with AOVPN that occurs when user and device tunnels are configured to connect to the same endpoint.

    Addresses an issue that causes VPN apps to stop working in some cases when they attempt to enumerate VPN profiles.

    Reply
  18. I’m facing the same issue about the IKEv2 with build 2004. Any updates?

    Reply
  19. Julian

     /  July 4, 2023

    Hello Richard,

    i have the same problem currently with my Windows 11 22H2 test device, any ideas why this is happening? (user & device tunnel)

    Usertunnel with ikev2 & sstp fallback (split tunnel)

    Thank you,
    Julian

    Reply
    • As long as your endpoint is fully updated, it should work. However, there seems to always be issues with connection reliability after sleep/hibernate.

      Reply
      • Julian

         /  July 12, 2023

        Hello Richard,

        thanks for your fast answer. First i would like to thank you for your great knowledge base your have build on this website. It is really helpful. I also bought your Deployment Guide book, great insight into this Always On Topic.

        Additional information to my problem:

        The behaviour is really strange. It worked normally without any problems a few weeks ago – nothing changed, except installed updates on server (2019) and client.

        Strange thing: If i do not put the public IP address resolving to the DNS name used for the VPN connection into the local hosts file i get the error 809. If i add the public IP & VPN dns name into the hosts file i get error 619. Maybe some kind of resolving issue?

        On the firewall we can see that ports 443, 500 & 4500 are going through.

        I also noticed that the “SYSTEM” user wants to conect with the usertunnel – is that the way it’s meant to be?

        If i remember right – when it worked – the logged on user should initate the connection with the usertunnel, correct?

        Devicetunnel works fine, everytime. Profiles are deployed through Intune.

        Thank you and best regards,
        Julian

      • It could certainly be DNS. If the device tunnel is up its possible the public hostname is being resolved over the tunnel. Make sure the public hostname resolves correctly to the public IP address over the device tunnel. As for the SYSTEM account starting the user tunnel, I’m not sure. Certainly when the user tunnel is deployed in the ‘all users’ context I’d expect that. I don’t think that’s the case when the user tunnel is deployed in the user’s context though.

      • Julian

         /  July 13, 2023

        I managed to solve my issue! I don’t know why, but on my NPS Server (dedicated) i saw in the NPS Service logs the following entry:

        A RADIUS message was received from the invalid RADIUS client IP address xxx.xxx.xxx.xxx.

        This IP address was our Firewall, on which the SNAT was configured to NAT to the DMZ IP Interface of our VPN-Server.

        After i added the Firewall as RADIUS Client to my NPS-Server the Usertunnel worked finally.

        Greetings,
        Julian

      • Great to hear! 🙂

  1. Always On VPN Updates for Windows 10 2004 | Richard M. Hicks Consulting, Inc.

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading