An 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
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
ced666
/ April 13, 2018Hi 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.
Patrck.
Richard M. Hicks
/ April 14, 2018Again, 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, 2018Will 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.
Richard M. Hicks
/ April 23, 2018To my understanding, no. You’ll need to upgrade to 1803.
Andy
/ April 24, 2018Do 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?
Richard M. Hicks
/ April 24, 2018The 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.
ced666
/ April 16, 2018Thank 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
Patrick
PATRICK
/ April 23, 2018Hello 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.
Patrick
Richard M. Hicks
/ April 23, 2018Excellent news! 🙂
Richard M. Hicks
/ April 23, 2018Also, 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.
ced666
/ April 24, 2018Hello Richard,
thank you
It’s a shame because no remote maintenance is possible through the vpn tunnel to the client station.
Patrick
Mincey
/ May 1, 2018Richard, 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.
Richard M. Hicks
/ May 3, 2018I 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.
ced666
/ May 23, 2018Hello 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?
Richard M. Hicks
/ May 23, 2018I 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.
ced666
/ May 24, 2018Hello 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
Richard M. Hicks
/ May 24, 2018Good to know!
wes
/ July 30, 2018Would 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?
Richard M. Hicks
/ July 30, 2018No idea…I’m not familiar at all with autopilot. However, would offline-domain join accomplish what you want?
https://directaccess.richardhicks.com/2015/06/22/provisioning-directaccess-clients-using-windows-offline-domain-join/
Wes
/ July 30, 2018Autopilot 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
Richard M. Hicks
/ July 30, 2018Great. 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. 🙂
andychips
/ August 8, 2018I’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?
Richard M. Hicks
/ August 8, 2018I’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.
andychips
/ August 9, 2018Thanks 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.
Richard M. Hicks
/ August 14, 2018No question it is getting better. As long as you are on 1803 with the latest updates you’ll likely be ok in most scenarios.
Pat666
/ November 25, 2018Hello 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.
Patrick
Richard M. Hicks
/ November 29, 2018I don’t know for certain. It is possible, but I don’t recall ever seeing the KB for it.
Patrick
/ November 27, 2018Hello Richard,
Can I have the official Microsoft source like this bug (RASMAN EventID 1000) has been fixed in release 1803?
Thank you
Patrick
Richard M. Hicks
/ November 29, 2018Sorry, I don’t have that. As it wasn’t released in a cumulative update I don’t have any reference documentation for you.
ced666
/ November 29, 2018Hello 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.
Patrick
Richard M. Hicks
/ November 29, 2018All 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. 🙂
Pat666
/ December 5, 2018Hi 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.
Patrick
Mark Besselink
/ December 13, 2018A 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.
Mark
Richard M. Hicks
/ December 18, 2018Thanks!
Nick
/ June 6, 2019Hi 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.
Richard M. Hicks
/ June 7, 2019You are the first I’ve heard report this. 1903 has been working flawlessly for me so far. 🙂
Alexander Teterra
/ June 17, 2019Hi Nick, did you use a devicetunnel Setup with ikev2? We have the same issue. Greetings Alex
Patrick
/ June 20, 2019Hello 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?
Patrick