Always On VPN RasMan Device Tunnel Failure

Always On VPN RasMan Device Tunnel FailureAn Always On VPN device tunnel is an optional configuration for Windows 10 Enterprise edition clients designed to provide machine-level remote network connectivity. This capability provides feature parity with DirectAccess for domain-joined clients to support scenarios such as logging on without cached credentials and unattended remote support, among others.

Device Tunnel Failure

When configuring a Windows 10 client to use an Always On VPN device tunnel, you may find that the device tunnel works without issue after initial deployment but fails to connect after the computer restarts. In addition, the Windows event log will include an Event ID: 1000 application error with the following error message:

Faulting application name: svchost.exe_RasMan

Always On VPN RasMan Device Tunnel Failure

Known Issue

This can occur when a Windows 10 machine is configured with a device tunnel only (no user tunnel). This is a known issue with Windows 10 v1709. It has been resolved in Windows 10 v1803 (RS4).

Additional Information

Windows 10 Always On VPN Device Tunnel Step-by-Step Configuration using Powershell

Deleting an Always On VPN Device Tunnel

Leave a comment


  1. ced666

     /  April 13, 2018

    Hi Richard,

    How did you manage to make tunnel device mode work more accurately. I followed your procedure step by step but impossible to operate the tunnel device, does this principle work in a virtual environment. I really have doubts because it is currently impossible to operate the tunnel vpn device mode. how do you write the xml file with ./Device/Vendor / ….
    can I have a concrete example please.


    • Again, your client will require Internet access for this to work. If the NCSI reports “no Internet” the tunnel won’t work. It should work without issue in a virtual machine, but it won’t work after restart if you have only the device tunnel due to a known issue in Windows v1709.

      • Andy

         /  April 23, 2018

        Will it not be fixed in 1709?, I’ve raised a Sev B with Premier support to confirm but they are so busy they are only dealing with Sev A’s at the moment.

      • To my understanding, no. You’ll need to upgrade to 1803.

      • Andy

         /  April 24, 2018

        Do you know if there are any functionality or risks not having the device tunnel when using 1709 or whether if affects the user tunnel? We are trying to establish whether to proceed with 1709 or wait for 1803 before rolling out a VPN project. What would you do?

      • The Windows 10 Always On VPN device tunnel is optional and only required to support scenarios such as logging on without cached credentials. If you don’t have any specific requirements for the device tunnel, you can safely deploy Always On VPN without it. If you really need the device tunnel, then I’d definitely wait for 1803.

  2. Thank you very much Richard, so I will test the tunnel device VPN from a client with Internet connection. I will also test if the bug has been fixed in the version 1803 Windows


  3. Hello Richard,
    I confirm that the bug (eventID 1000) has been fixed in the version of Windows 1803 build (17127). After restarting, the tunnel is well mounted. However, all incoming traffic in tunnel device mode is still blocked.

    • Excellent news! 🙂

    • Also, regarding incoming traffic being blocked on the device tunnel, that is a known issue that occurs when using traffic filters. Once a traffic filter is defined, all inbound traffic will be denied. It is not a bug, but a missing feature. Hopefully that will be resolved in a future release of Windows.

  4. ced666

     /  April 24, 2018

    Hello Richard,
    thank you
    It’s a shame because no remote maintenance is possible through the vpn tunnel to the client station.


  5. Mincey

     /  May 1, 2018

    Richard, from your comments above it seems that there is some work being put into 1803 to solve AlwaysOn VPN issues.

    Now that 1803 has been released we have been trying to find out what benefits there are using 1803 over 1709. However, we haven’t been able to find references to any VPN bug fixes or improvements in any of the released information.

    Is it your understanding that there are benefits in moving to 1803 to solve previous VPN issues that were present in 1709?

    For example, the issue where the User Tunnel does not automatically connect when using ‘Trusted Network Detection’ in the user tunnel config, combined with using a Device Tunnel.

    • I am only aware that the device tunnel RasMan crash was resolved in 1803. There were most likely some other bugs that I’m not aware of that were resolved. I’m not aware of any new features/functionality for Always On VPN in 1803, however.

  6. ced666

     /  May 23, 2018

    Hello Richard,

    just to let you know that LockDown always blocks incoming connections even if traffic filters are not used. According to you, will this be corrected in future versions namely the ability to allow incoming connxions to the VPN client station even in LockDown mode?

    • I haven’t done any testing with lockdown VPN, but I understand that it won’t allow any traffic in or out if the VPN has not been established. The issue with traffic filters is still in effect though. You’re right, as soon as you create a traffic filter, all inbound traffic is denied. Hopefully this will be addressed in a future release of Windows.

  7. ced666

     /  May 24, 2018

    Hello Richard,
    Lockdown VPN blocks traffic In even when the VPN tunnel is mounted.

    In summary, the same Lockdown mode without using the traffic filter, all incoming traffic is blocked regardless of the state of the VPN tunnel

  8. wes

     /  July 30, 2018

    Would it be possible to use the device tunnel for autopilot hybrid domain join initialization – at which point DirectAccess configuration would get picked up and then vpn would no longer be needed anymore?

    • No idea…I’m not familiar at all with autopilot. However, would offline-domain join accomplish what you want?

      • Wes

         /  July 30, 2018

        Autopilot allows machines to ship directly from OEMs to end users and when they turn them on and sign in with their corporate credentials the machine autoconfigures itself for use with azure AD etc.

        It will soon support hybrid azure ad join but to do so it requires line of sight to a domain controller – so machine tunnel is what the internal MS team is recommending for that piece

      • Great. So yes, Always On VPN device tunnel would certainly work in that scenario as it would provide pre-logon connectivity to the domain to facilitate logging on without cached credentials. The assumption would be that the computer certificate and Always On VPN settings would be in place before that happens, of course. 🙂

  9. I’m trialling AlwaysOn with about 10 users and one or two of the Device Tunnel users are intermittantly getting double connections to the RRAS server.

    The user will be happily working away when *something* occurs to initiate a second connection. As soon as this second active connection occurs the client cannot reach any resources apart from the Internet. They just stay connected for ages and don’t disconnect even if the client is switched off.

    The only fix is to manually disconnect that client’s sessions on the server and they’re immediately back up and running. It’s always machines with device tunnels (build 1803) and very intermittant. User tunnels don’t seem to be affected in the same way.

    Any clues?

    • I’ve not encountered that specific scenario myself. Definitely feeling some pain with device tunnel and user tunnel stability in general, but not specifically that issue.

      • Thanks Richard,
        That’s a shame. Thought you might have had a quick answer to that.
        I’m find the general stability really good, and people love the transparency of it. As you allude to, there are a few snags for MS to iron out yet.

      • No question it is getting better. As long as you are on 1803 with the latest updates you’ll likely be ok in most scenarios.

  10. Hello Richard

    Do you know if the RASAM bug (eventID 1000) has been fixed via cumulative updates in the version of Windows 10 1709?

    Thank you.


  11. Hello Richard,

    Can I have the official Microsoft source like this bug (RASMAN EventID 1000) has been fixed in release 1803?

    Thank you


  12. ced666

     /  November 29, 2018

    Hello Richard,

    Why are my requests not posted and not processed?

    Do you have the official Microsoft source about the operating bug of the Windows 10 1709 tunnel device and fixed in the build 1803?

    I thank you in advance.


    • All comments require approval because of the level of spam I receive. Sorry! Also, I don’t process comments every day. If you need a faster response, consider reaching out to me on Twitter or via email. 🙂

      • Hi Richard,

        no wonder this bug is not really at Microsoft. The bug is not only related with Windows 10 but also with the gateway RAS Windows Server 2016. I redid the tests, at startup the tunnel is well planted the error ID 1000 with a gateway VPN RAS. On the other hand with a third gateway, I have the error ID 1000 but the tunnel is mounted despite everything. For your information, I updated the latest cumulative update 16.299.820 of Windows 10 1709 and the error is no longer present with a third-party gateway. I did not retest with a VPN RAS gateway. This subject makes confusion as to the use of tunnel device mode. I confirm that this mode is functional under Windows 10 1709 with a VPN gateway worthy of the name.


  13. Mark Besselink

     /  December 13, 2018

    A quickfix for build 1709, create a scheduled task that triggers on event id 1000, cause evenid 1000 is very generic, create custom filter XML trigger for this scheduled task by putting something unique from the error message (you find it in the application logs) in the general tab (this can be different with other languages of the OS)
    Example: *[EventData[Data and (Data=’Faulting application name: svchost.exe_RasMan’)]]

    Then create two actions:
    – c:\windows\system32\rasdial.exe /disconnect
    – c:\windows\system32\rasdial.exe

    Let it run under the system account with highest privileges.

    As alternative the same sort of quickfix can be applied if you could trigger something in the eventlog when the wireless adapter is connected.

    Hope this will help others, that wil skip 1803 but needed the device tunnel for login without cashed credentials.

    Greets from Holland.


  14. Nick

     /  June 6, 2019

    Hi There Richard
    We are seeing Rasman crashing on 1903 again now, have you heard anything about this?
    The exact same profile was working fine on 1803.
    I cant find any listing of this as a bug or fixed bug yet either.

    • You are the first I’ve heard report this. 1903 has been working flawlessly for me so far. 🙂

    • Alexander Teterra

       /  June 17, 2019

      Hi Nick, did you use a devicetunnel Setup with ikev2? We have the same issue. Greetings Alex

    • Hello Nick
      I installed the Windows version 101903 (OS build 18362.30) and I did not find a RASMAN crash in the tunnel device. I restarted the post several times and the rasman bug is not present. The tunnel is well mounted before logging on.
      Can you send us the event ID related to the RASMAN crash?


  1. Always On VPN Device Tunnel Missing in Windows 10 UI | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Device Tunnel Missing in Windows 10 UI | Richard M. Hicks Consulting, Inc.

Leave a Reply

%d bloggers like this: