Windowsserverdocs: Trusted network detection - Device tunnel and User tunnel

[DanNHS]

Is there a configuration example you can provide that will enable me to use trusted network detection on both the Device tunnel and Always-On User tunnel?
Currently the User tunnel does not connect if the Device tunnel is connected as it sees the domain down the Device tunnel. The Device tunnel is restricted to only enable access to one DC and an SCCM DP/MP to enable a non cached user to login and device management. The User tunnel allows access to a much broader range of services on the network the the user will need once logged in.
I have tried this in 1709 and 1803 and am not having any luck.
Thanks
Dan

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 06629f78-c4b1-4345-578c-596e92dff977
• Version Independent ID: e3686eef-c2c6-5a21-ac76-6bac575e7cfc
• Content: Configure the VPN device tunnel in Windows 10
• Content Source: WindowsServerDocs/remote/remote-access/vpn/vpn-device-tunnel-config.md
• Service: unspecified
• Product: windows-server-threshold
• GitHub Login: @shortpatti
• Microsoft Alias: pashort

[shortpatti]

@DanNHS, thank you for your feedback. I am working with the engineer to update this content based on the feedback received so far. I'll ask to have a configuration example to use trusted network detection.

[DanNHS]

Thank you. I am not sure if it is a bug or that I have not configured it correctly.
Would you be able to check with the engineer if it is possible to enable trusted network detection on both the Device tunnel and Always-On User tunnel at the same time and expect them both to work please?

[k3rnelpanic640]

I've also come across this issue. If I don't put a DC IP address in the configuration then it works fine but then new users can't login.

This is holding back our move from directaccess to always on VPN so hopefully there is a solution.

[DanNHS]

Yes that is my experience as well. If I don't add a DC IP to the host routes and traffic filters section then the User tunnel connects fine but a non-cached user then can't login, largely defeating the point of the Device tunnel, at least from the users point of view.

[shortpatti]

The engineering team is investigating the issue.

[shortpatti]

Hi, can you both answer the following questions:
1) Are they using Forced tunnel on both profiles?
2) Can they share the profile XML for both device and user?

[DanNHS]

I am not using Force tunnel in either profile, both are setup as Split tunnel config.
Attached is a txt file of both my XMLs with some server addresses and EAP info removed.
TunnelXMLFiles.txt

[ChristianOe]

Hi, I can confirm @DanNHS issue. My devicetunnel uses the SplitTunnel type, disabled classbaseddefaultroute, is AlwaysOn, RegisterDNS is true and got the right Domain for the TrustedNetworkDetection. As TrafficFilters I configure all AD Server, SCCM Server IP addresses.
The Network Detection can determine the Domain and it is the same Domain as configured as TrustedNetworkDetection. After I connect to the Usertunnel the Devicetunnel does not disconnect. If I leave the AD Server outside the configuration of the device tunnel and the Network detection can not determine the Domain Network then the trigger is working and the devicetunnel disconnects after connecting to the usertunnel.

Any advice?

[shortpatti]

Hi @DanNHS and @ChristianOe, the engineering team is aware of this issue and they are investigating a similar issue. I've also provided the information as part of their investigation process.

[DanNHS]

Hi @shortpatti do you have an ETA for a resolution please?
Thanks
Dan

[shortpatti]

Hi @DanNHS, I have no ETA yet.

[DanNHS]

Hi @shortpatti does this look like it will get fixed soon or is it going to be a long haul type of issue?
Thanks
Dan

[jesus-francisco]

Waiting for the fix for the Device Tunnel to work as well so that GPOs can be enforced to remote user when they are login to the computer.

[jesus-francisco]

RegisterdDNS doesnt work either, the VPN gets connected but the check on VPN Profile > Properties > Networking >IPv4 > Properties > Advanced > DNS > "Register this connection's addresses in DNS" is not getting checked with the profileXML.
I tried with a method I found but the method only works on Physical Interface no VPN Profiles, leaving those steps reachable only manually.
It is a secondary problem apart from the fact that the Device VPN is not connecting after bootup but having the new VPN IP Registered on the DNS is needed as well to have a functional AO-DeviceVPN.

[shortpatti]

Thank you for providing some details.

Engineering is working with a customer on gathering logs to understand the behavior:
Bug 17581374: [DHS AU] Device tunnel using forced tunnel does not allow user profile auto trigger.

Please provide the following information:
1) Can you provide details on Device and User tunnel is configured?
2) Are you using Trusted network detection?
3) Are you using Force tunnel?
4) What Windows Build are you currently on (e.g. 1709 – RS3, 1803 – RS4)?

[jesus-francisco]

Please provide the following information:

Can you provide details on Device and User tunnel is configured?
I tried to confiugure a Device Tunnel and it manage to get created but the
tunnel never
auto connect not when a user is logged io neither when a user is logged on.
If I put the Devicetunnel
to false ( false) then it works like a charm
but just when the user
login into the computer even when the autheticaton is
[Certificate] on
both scenarios. And true does not work on false
or true, same result.

Are you using Trusted network detection?
yes Im using [' + $TrustedNetwork +
'] and it works
I tested it connecting a laptop to the corporate network and it keeps the
VPN Disconnected.

Are you using Force tunnel?
I tried at some point but the outcome was the same, right now I have it
with AlwaysON.True,
AutoTrigger.True and Persistent.True as well. I can try with FOrceTunnel
again and will reach you if it
makes it work and send you a copy of my PS1.

What Windows Build are you currently on (e.g. 1709 – RS3, 1803 – RS4)?
Windows 10 Pro - Version 1709 - OS Build 16299.431

On Wed, Jun 13, 2018 at 8:45 AM Patti Short [e-mail]
wrote:

Thank you for providing some details.

Engineering is working with a customer on gathering logs to understand the
behavior:
Bug 17581374
https://microsoft.visualstudio.com/OS/_workitems/edit/17581374?fullScreen=false:
[DHS AU] Device tunnel using forced tunnel does not allow user profile auto
trigger.

Please provide the following information:

1. Can you provide details on Device and User tunnel is configured?
2. Are you using Trusted network detection?
3. Are you using Force tunnel?
4. What Windows Build are you currently on (e.g. 1709 – RS3, 1803 –
   RS4)?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/windowsserverdocs/issues/900#issuecomment-396924207,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AmX2h0rzKAUPEi7CHQEzMBbOpWV4y66qks5t8QlUgaJpZM4UTLDq
.

--

Jesús Francisco

[jesus-francisco]

This is the output that I'm getting:

#

__SUPERCLASS :
__DYNASTY : MDM_VPNv2_01
__RELPATH : MDM_VPNv2_01.InstanceID="AOV",ParentID="./Vendor/MSFT/VPNv2"
__PROPERTY_COUNT : 10
__DERIVATION : {}
__SERVER : ABC-DEFG-1234
__NAMESPACE : rootcimv2mdmdmmap
__PATH : \ABC-DEFG-1234rootcimv2mdmdmmap:MDM_VPNv2_01.InstanceID="AOV",ParentID="./Vendo
r/MSFT/VPNv2"
AlwaysOn : True
ByPassForLocal :
DnsSuffix : ABCD.local
EdpModeId :
InstanceID : AOV
LockDown :
ParentID : ./Vendor/MSFT/VPNv2
ProfileXML : truefalseABCD.local nsSuffix>ABCD.locala
ov.ABC.com;aov.ABC.comSplitTunnel

Ikev2Certificate ineMethod>ABCD.local nName>10.10.10.10true true
RememberCredentials :
TrustedNetworkDetection : ABCD.local
PSComputerName : ABC-DEFG-1234

#

I changed the value to false to test it will work backward but then it assumed the default false of DeviceTunnel and doesnt even show it up on the ProfileXML output.
I tried without the AlwaysON.true as well since the DeviceTunnel is an AlwaysOn on itself and either way got the same results, not being able to login with another user or get the computer connected without having a user logged on it. As soon as I login with any cached user, the VPN comes up right the way by itself.

I read somewhere that it is supposed to be for Windows Enterprise only, is that right?

[bdecock-minfin]

Just to let you know.
Device tunnel with a dc and sccm mp + user tunnel works fine with Windows 10 Enterprise (build 1803) and windows server build 1803.
The device tunnel disconnects as soon as the user tunnel comes up and reconnects if I disconnect the user tunnel.
As for the register dns option the value should be true and not True

[mrhaggis]

I also have a device and a user tunnel configured on 1803, however i am pretty sure that the device tunnel disconnecting when the user tunnel connects is not the correct behaviour, and i can't find anywhere in the documentation to confirm if BOTH tunnels should be staying up at the same time, i suspect they should, or it makes manage-out via the device tunnel when logged on not work otherwise.

[shortpatti]

Hi @mrhaggis, the engineering team is still working on a resolution.

[NeighborGeek]

@shortpatti - I'm also experiencing this behavior. It seems that when Trusted Network Detection for the user tunnel checks whether the computer is already on the trusted network, because the device tunnel is already connected and allows traffic to a domain controller, Trusted Network Detection determines that it is on the trusted network and does not initiate the VPN connection.

I note that the bug title you posted previously specifies that this happens when using force tunnel. In my case, I do NOT have force tunnel configured on either the device tunnel or the user tunnel.

I'm testing this on a computer running win10 v1803.
Trusted Network Detection is enabled for both the Device and User tunnels
If you need detailed config info for the tunnels, let me know and I'd be happy to share it privately.

[mrhaggis]

i have actually managed to have a device and user tunnel both be active at the same time for a prolonged time, this is without using trustednetworkdetection on either tunnel, and using Split tunnel on both user and device tunnels. However it is less than consistent, the coding added for the device tunnel just seems to be bugged as it works on some devices most of the time, but different devices with the EXACT same configs applied give different results. using trustednetworkdetection is just not an option as it stands as the logic for it seem hopelessly broken as it can see your network down the other tunnel. we also are testing on 1803 with the latest cumulative updates applied.

We have logged a case with Premier support, and after waiting 8 days for an engineer to be assigned yesterday, are hoping to be able to start working with them to find the bugs.

[jesus-francisco]

@mrhaggis, can you authenticate on any new computer over the VPN with a non cached account? or the question is, does the DeviceVPN comes online on before the user login or after the user login?

[NeighborGeek]

@mrhaggis - Yes, I've also got both tunnels to work at the same time, if TrustedNetworkDetection is not used. The down side to this is that then when the computer is on our internal network, the VPN connections attempt to connect and fail, since they can't reach the VPN server's outside interface. I believe that happens repeatedly, but don't have one set up that way at the moment to confirm.

The trustednetworkdetection for the user tunnel needs to be smart enough to know that if the only access to the trusted network is over the device tunnel, the User tunnel needs to be established as well.

[ianc911]

I'm having trouble understanding why you would want to deploy both a user tunnel and a device tunnel at the same time; unless it's just for fun? What does having a user tunnel buy you that you wouldn't get already having device tunnels?

I like device tunnels because the machine is reachable for management purposes, but the downside seems to be that it's not easy to disallow a machine from connecting since machine cert auth doesn't use NPS; hence the only way would be to revoke the machine's cert. If you have a week long CRL validity period with a week's overlap, this isn't really optimal?

Sorry, I know this isn't the best forum for questions, but I keep coming back here looking for info as there seems to be virtually nothing published on the subject anywhere...

[mrhaggis]

Hi @ianc911, the idea is to give parity with the way it worked in DirectAccess with its two tunnels, the device tunnel is only allowed access to just enough servers for someone to be able to log on, so stuff like DCs, AV, SCCM etc servers would be allowed to talk via the Device Tunnel pre-logon. And it only does that using a machine certificate with no NPS involvement like you say. and you can do Manage out to machines that are not logged on

Once they logon the user cert is authenticated via NPS, and via the user tunnel they now are granted access to all the services of your network, so file shares , application servers etc. the device tunnel is supposed to also stay connected so you can still manage out your devices via an IP registered in DNS.

I suppose you could allow access to everything via the device tunnel only, but as that is established just via the machine cert, anybody logging onto that device, even non network users would be effectively on your corporate network, with network access to all servers, with just NTFS permissions blocking them from accessing servers for example.

At least that's my understanding of how its all supposed to work, my testing has shown it to be less than polished, with some issues that still need to be fixed by the development team before we can start a serious rollout of it.

[ianc911]

Hi mrhaggis,
What you say makes sense, so thanks for the explanation. Seems like it would be optimal if machine cert auth could happen via NPS with EAPPEAP; then access could be based on Windows groups. Wonder if there's a way to make that happen?
I agree that the whole thing is kind of half-baked as of now; hopefully they can continue to get it sorted out.
Thanks again,
ianc

[shortpatti]

Thank you, everyone, on this thread who have clarified things for everyone 💯 The open collaboration helps improve the documentation. I'll touch base with the networking team to find out the status of this issue. I'll keep this thread up to date.

[julianddavidson]

A device tunnel for remote management and non-cached user logons would be enough for me at the moment. Are there powershell commands I can use for troubleshooting purposes? IE> to see what's going on and make windows attempt to connect, rather than having to wait. I'm currently getting 809 errors, so working through that. Thanks

[ianc911]

Troubleshooting IPSEC is kind of a black art to me...

You can try to manually connect & disconnect the VPN connection object from a command prompt using:

rasdial.exe connectionobjectname /disconnect

[julianddavidson]

Me too. I've taken quite a long time to get to this point. Got so close using Richard Hicks' guides, and then found the comments on this page saying it's not really viable yet. I just found the adapter in the control panel too, so at least I've got a button now.

[mrhaggis]

for the device tunnel, you can connect and disconnect by using either the rasdial.exe from a command prompt, or you can open the C:programdataMicrosoftNetworkConnectionsPbkrasphone.pbk by double clicking it , you get a nice "connect" and "hang up" button for testing it. Also any change in the network connections, such as disabling and reenabling your Wi-Fi adapter will kick Windows into attempting to reconnect. I think 809 errors are when it thinks it cannot even talk the VPN URL, remote server not responding. Microsoft have a useful page with all the RRAS error codes on it - https://docs.microsoft.com/en-us/windows/desktop/rras/routing-and-remote-access-error-codes

[ianc911]

Is there a way to get a computer to authenticate with its cert using EAPNPS rather than directly on the RRAS server? This snippet:

TestVpnProfile

testServer.VPN.com
IKEv2

<!--Sample EAP profile (PEAP)--> 
<Authentication>  
  <UserMethod>Eap</UserMethod>  
  <MachineMethod>Eap</MachineMethod>  
  <Eap>

found here: https://docs.microsoft.com/en-us/windows/security/identity-protection/vpn/vpn-profile-options

seems to indicate it can be done. Not having any success however...

[DanNHS]

Hi @shortpatti do you have any idea when this issue might be fixed please?

[shortpatti]

@DanNHS, Thanks for asking about the status. The engineering team is still working through the issue. I'll reach out to them and find out an ETA :)

[Hampti]

Hi @shortpatti
Are there already news regarding this Problem?

[Alelieveld]

Hi @shortpatti
Do you have an update regarding this issue?

[shortpatti]

I'll be reaching out to engineering today to get an update on this issue and a few others that might be related to this issue.

Thank you for checking :)

[ptimens]

Hi!
Is there any update yet?

[Alelieveld]

Hi @shortpatti Any news on this?

[shortpatti]

Sadly, the only news I have is the following (the same as last week):

A fix was introduced in RS5 and tested by CSS engineer with a customer.

It’s also in the process of getting serviced in RS4.

Bug 18032215 - Trusted Network Detection unreliable in dual tunnel AlwaysOn VPN configs

I'll continue to poke as much as I can to get answers.

[bdecock-minfin]

Sorry Patti,

This just means stop using the product as it’s advertised.
Which although a solution, isn’t the solution -;)

Kr,

Ben

[shortpatti]

The engineering team is ACTIVELY working on this and other related bugs.

Thank you for your patience!

[julianddavidson]

Hi @shortpatti .. are there plans to make this configurable via Group Policy? This would make it much easier to deploy to domain computers. Cheers.

[shortpatti]

@julianddavidson, I totally agree with the group policy. Let me check with the engineering team to see if that is a possibility.

[julianddavidson]

@shortpatti Thanks. Because of the early support for MDM deployment I got the idea that it was aimed at BYOD scenarios. But if we're supposed to be considering this as a direct access replacement then domain / group policy support is a must. We don't use MDM for domain devices and if I have to use powershell/XML then I'm going to wait a long time before I bother with this.

[jonesaj5]

Sorry all I am at the start of deploying this. Simple question - is there a way when just using a user tunnel to prevent users from disconnecting. Is there a setting I can configure in the profile for this ?
Alternatively If I just deployed device tunnels to replace the user tunnel would this solve my question above ?

[bdecock-minfin]

@shortpatti any update on the servicing for RS4?
I would like to test this in RS4 so we are sure it works ;-)
Happy to open a Premier case to get the hotfix to test if needed.

[shortpatti]

@bdecock-minfin, I know they are working on it, so go ahead and open a Premier case. I'll poke the engineers about the status as well.

[DanNHS]

@shortpatti With the release of RS5 imminent is there any chance of an ETA for this fix in RS4 or a confirmation of it being included in RS5?

[bdecock-minfin]

I've opened a case with Premier support and got the fix for rs4. release date would be the 17th.
But unfortunatly the fix worked once and then the same result as mentioned above.
Device tunnel comes up perfectly but user tunnel stays in connecting status. or device tunnel up but goes down when user tunnel comes up. Or anotherwise stabele connection disconnects every 5-10min.
This is with splittunnel on both and trusted network detection on both + DC ip on device tunnel.
So I guess it's back to the drawing board :(

[mrhaggis]

HI, we also got the fix for the trusted network detection logic via a premier case, however there are still couple of other outstanding issues with Always on VPN device tunnel that mean it isnt really ready to deploy yet. both of which we have as outstanding issues with Premier and are hopefully going to be working with them to test more patches when released.
I have to say, the guy we are working with at Premier really knows his stuff, i couldnt be more impressed by his knowledge, we are just waiting on the actual product group to figure out how to incorporate a fix for the issues, which i think are pretty complex and deeply embedded in the network stack, so they seem fairly reluctant to issue a quick fix.

1) It doesnt behave the same on wired vs wireless due to it not properly changing the metric for the IPv6 wired adapters, this means the VPN sends some traffic outside of the VPN to the ISP over the IPv6 ethernet adapter instead of down the VPN, such as DNS queries, the only full fix from Microsoft so far is to disable IPv6 on the wired adapters.
2) there is a problem with some of the core network APIs called by the Always on VPN which determine the best way to send the VPN traffic, in some cases, when the user tunnel comes up, the device tunnel suddenly decides the users tunnel looks like a good place to send all the traffic, so the device tunnel disconnects, trys to reconnect but send all its traffic via the user tunnel, not an actual NIC, and it all falls over in a big messy heap. this issue only occured for us on certain models of devices, on other devices we had a rock solid connection of both the user and device tunnel at the same time (with the patch applied)

Until both these issues are fixed, we are holding off deploying the device tunnel at all, and are just using the user tunnel only.

Cheers
Andrew

[CodyMathis123]

HI, we also got the fix for the trusted network detection logic via a premier case, however there are still couple of other outstanding issues with Always on VPN device tunnel that mean it isnt really ready to deploy yet. both of which we have as outstanding issues with Premier and are hopefully going to be working with them to test more patches when released.
I have to say, the guy we are working with at Premier really knows his stuff, i couldnt be more impressed by his knowledge, we are just waiting on the actual product group to figure out how to incorporate a fix for the issues, which i think are pretty complex and deeply embedded in the network stack, so they seem fairly reluctant to issue a quick fix.

1. It doesnt behave the same on wired vs wireless due to it not properly changing the metric for the IPv6 wired adapters, this means the VPN sends some traffic outside of the VPN to the ISP over the IPv6 ethernet adapter instead of down the VPN, such as DNS queries, the only full fix from Microsoft so far is to disable IPv6 on the wired adapters.
2. there is a problem with some of the core network APIs called by the Always on VPN which determine the best way to send the VPN traffic, in some cases, when the user tunnel comes up, the device tunnel suddenly decides the users tunnel looks like a good place to send all the traffic, so the device tunnel disconnects, trys to reconnect but send all its traffic via the user tunnel, not an actual NIC, and it all falls over in a big messy heap. this issue only occured for us on certain models of devices, on other devices we had a rock solid connection of both the user and device tunnel at the same time (with the patch applied)

Until both these issues are fixed, we are holding off deploying the device tunnel at all, and are just using the user tunnel only.

Cheers
Andrew

Hey Andrew, would you be able to share a sanitized profile XML? We are about to pilot Always on VPN and I wouldn't mind having a good reference for the 'dual tunnel' setup.

[yannara]

If deploying both user and device tunnels, I see user tunnel gets disconnected always. Treating this as a bug. Last tested on 1803 with 09-CU.

[julianddavidson]

@shortpatti Any response re support for group policy deployment? Cheers

[CodyMathis123]

If deploying both user and device tunnels, I see user tunnel gets disconnected always. Treating this as a bug. Last tested on 1803 with 09-CU.

Can confirm we are having this exact same issue....

[CodyMathis123]

@shortpatti any news on this? https://support.microsoft.com/en-us/help/4458469/windows-10-update-kb4458469 this has a fix... but this still does not work as intended.

[yannara]

Both tunnel works nice after CU 10-2018

[CodyMathis123]

Both tunnel works nice after CU 10-2018

Hmm... I'm seeing inconsistencies. Any chance you can share a sanitized set of profile XML?

[yannara]

Not right now, but I had the same bug before cu 10-2018.

[bdecock-minfin]

@ cody

Sorry to say but your link is to extensive to link with a device tunnel issue. Pease be more clear.

As for the device tunnel with dc’s in the routing:
I’ve had a case open with premier support for multiple months. And the latest private patch still doesn’t work as advertised.
Going in bigger details i noticed in my setup that although the device tunnel is working 90% of the time it opens up issues with authentication on the user tunnel which are not up to spec.
I’m talking about user tunnel authentication being established without mfa ( in my case) being requested... and actually having user tunnel access!!! I must admit this only happens 35% of my tests with their latest premier test patch release. And only if the “always on” is present on both profiles + dc routing in device profile.
At this point for me the device tunnel in conjunction with the user tunnel is considered to be something extra. When it becomes stable and secure i will need to re-evaluate if i can make use of it.

But in the current form device (with dc’s routed) + user tunnel is a NOGO.

Still hoping it will work correctly ;-)

Ben

On 13 Nov 2018, at 19:22, CodyMathis123 <[email protected][e-mail]> wrote:

@shortpattihttps://github.com/shortpatti any news on this? https://support.microsoft.com/en-us/help/4458469/windows-10-update-kb4458469 this has a fix... but this still does not work as intended.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windowsserverdocs/issues/900#issuecomment-438381757, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Amnba572Gf7IXl3flU2OhhE4BUnEb4QKks5uuw3PgaJpZM4UTLDq.

[CodyMathis123]

@bdecock-minfin Sorry about that! I should have been more specific.

In that KB there is a fix "Addresses an issue that prevents dual tunnel AlwaysOn VPN configurations that use trusted network detection from having both tunnels operational."

But, I have a similar setup to what you described, user and machine tunnel, with the device tunnel having a couple of DCs. What I seem to be running into is the Device Tunnel is disconnecting while the User Tunnel stays connected. If it was 100% consistent, I wouldn't mind... user logs off / reboots and the device tunnel reconnects, but that doesn't quite seem to be happening.

[DanNHS]

@shortpatti Can we have an update on the progress of this issue please? As yet this issue is still unresolved for me and the others who have posted on this issue.

[bdecock-minfin]

Dan,

I’m still busy with premier support.
So far i haven’t seen a stable test patch. (Device + dc + TND)

On 10 Dec 2018, at 16:19, DanNHS <[email protected][e-mail]> wrote:

@shortpattihttps://github.com/shortpatti Can we have an update on the progress of this issue please? As yet this issue is still unresolved for me and the others who have posted on this issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windowsserverdocs/issues/900#issuecomment-445852608, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Amnba-nU-fv7Yvs9_inMqQKUYuBF0nDuks5u3nuOgaJpZM4UTLDq.

[dcaddick]

Just checking if there has been any update on this issue?

[richardjellis]

Any update on this, @shortpatti ?

[ianc911]

Revisiting this 8 months after my initial pilots last Jun-Jul, but it doesn't look like there's been much in the way of progress here....

ianc

[efbertos]

I am having the same issue. Is microsoft doing anything with this? I am using user tunnel only.

[dmutsaers]

Using Device and User tunnels simultaneously. The User tunnel gets connected multiple times (about 4 times), and keeps disconnecting/reconnecting every 30 seconds. (1809, 17763.437).
It looks like it's still not working as expected?

[ianc911]

It really looks like MS is abandoning this. Has anyone tried it on Server 2019? Any improvements, or just as half baked on that platform?

[bdecock-minfin]

Testing on 2019 as wzme speak but the problem isn’t really rras but client side.
For me this stays a no go due to security risks and stabillity issues.

On 19 Apr 2019, at 17:53, ianc911 <[email protected][e-mail]> wrote:

It really looks like MS is abandoning this. Has anyone tried it on Server 2019? Any improvements, or just as half baked on that platform?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windowsserverdocs/issues/900#issuecomment-484939354, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJU5W24AEFU44ONGRY5KU53PRHTIVANCNFSM4FCMWDVA.

[DanNHS]

@shortpatti Can we have an update on the progress of this issue please?

[Anthoniusuk]

Is there any new news on this? We are using Server 2019 with Windows 10 1809 clients. Some of our computers are fine, others find that whichever tunnel establishes first is ok, the other can't stay connected, which is predominantly the user tunnel for obvious reasons. The computers that are impacted by this find that AOVPN tunnels over ethernet is fine, but over wireless is problematic.

[bdecock-minfin]

Running 2019 rras with win 10 1809 clients with azure mfa on top and for me the device+user tunnel still has to many issues.

Ben

Sent from my iPhone

On 29 Apr 2019, at 16:27, Anthoniusuk <[email protected][e-mail]> wrote:

Is there any new news on this? We are using Server 2019 with Windows 10 1809 clients. Some of our computers are fine, others find that whichever tunnel establishes first is ok, the other can't stay connected, which is predominantly the user tunnel for obvious reasons. The computers that are impacted by this find that AOVPN tunnels over ethernet is fine, but over wireless is problematic. The testing hasnt got a wide range of different models so we could draw the wrong conclusions, but the Microsoft devices are the stable ones as far as Always On VPN tunnels are concerned.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windowsserverdocs/issues/900#issuecomment-487601434, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJU5W2ZDRUGPTCCL7UBW723PS4AT5ANCNFSM4FCMWDVA.

[richardjellis]

@shortpatti Can we have an update on the progress of this issue please?

It looks like @shortpatti is no longer working for Microsoft.

[richardjellis]

@bdecock-minfin @mrhaggis I'm guessing you didn't get anywhere with premier support?

[richardjellis]

Is there any new news on this? We are using Server 2019 with Windows 10 1809 clients. Some of our computers are fine, others find that whichever tunnel establishes first is ok, the other can't stay connected, which is predominantly the user tunnel for obvious reasons. The computers that are impacted by this find that AOVPN tunnels over ethernet is fine, but over wireless is problematic.

I'm finding that the issue is completely unpredictable. Some devices have always worked fine. However devices which previously displayed issues (one tunnel drops whilst the other connects, then vice versa in perpetuity) may eventually "fix themselves" and behave correctly.

We are on server 2016 and 1709. FWIW we also have Cisco AnyConnect deployed for managing network connections but not VPN.

I note that the April 2 2019 update for 1809 (KB4490481) mentions fixes for AOVPN. Is anyone able to test?

[bdecock-minfin]

The april 2 patch only has to do with exclusion routes . Ie. You want to route whatever ... part from xx over the vpn tunnel.

I do know of a bug (premier case open atm) that has to do with the user tunnel, to be more precise, having routes defined in your vpn xml not being applied all the time, when making use of the network fly-out (widget), when the default class based routing is disabled in the profile.
Device tunnels are still what they were a year ago... might work, might fail... but all in all nothing compaired to the DA system tunnel.

Onlything i can say is .... log premier cases....and revisit in 6 months.

Kr,

Ben

On 29 Apr 2019, at 23:31, Rich Ellis <[email protected][e-mail]> wrote:

Is there any new news on this? We are using Server 2019 with Windows 10 1809 clients. Some of our computers are fine, others find that whichever tunnel establishes first is ok, the other can't stay connected, which is predominantly the user tunnel for obvious reasons. The computers that are impacted by this find that AOVPN tunnels over ethernet is fine, but over wireless is problematic.

I'm finding that the issue is completely unpredictable. Some devices have always worked fine. However devices which previously displayed issues (one tunnel drops whilst the other connects, then vice versa in perpetuity) may eventually "fix themselves" and behave correctly.

We are on server 2016 and 1709. FWIW we also have Cisco AnyConnect deployed for managing network connections but not VPN.

I note that the April 2 2019 update for 1809 (KB4490481https://support.microsoft.com/en-us/help/4490481) mentions fixes for AOVPN. Is anyone able to test?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windowsserverdocs/issues/900#issuecomment-487751589, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJU5W27M7A4ENDU5GC3KNZLPS5SJ3ANCNFSM4FCMWDVA.

[shareonline]

I have spent the last week setting up Always on VPN in different scenarios, to find out if it is production ready.
I must admit that I really don't think it is.. It is really unpredictable at times, and we can't really deploy such a solution to our customers.
One of my biggest problems is that the device tunnel sometimes locks up. A rasdial /disconnect only works sometimes, and if still stuck i have to kill rasdial.exe, disable my network card, and disconnect again. A reboot of course also works.
Now i spend a lot of time on this, so i also reinstalled my PC from scratch. The only thing on here is the vpn tunnels now. Still i have problems.
When it works GREAT, but that is only like 80% of the time, and that is not good enough..

It just seems like such a standard piece of functionality today, that it really bothers me that MS can't get this completely right. It's not like Always on VPN is a new product by now!

And oh yeah server 2019 and W10 1903 with IKEv2 fragmentation enabled...

[yannara]

1903 is brand new and might have issues. 1809 was fiasco all the time. My lab works great with W2019 and 1803, IKEv2.

[shareonline]

1903 is brand new and might have issues. 1809 was fiasco all the time. My lab works great with W2019 and 1803, IKEv2.

The fix really can't be to keep our customers Windows version two releases back :)
1903 is a production build, but fair enough, 1809 should at least be more stable than 1803! If the product get's worse over time, no reason for any of us being here in this thread?

[yannara]

You are not the only one. And I am talking about builds globally, not just about alovpn.

[cnschindler]

Any update on this issue? I'm experiencing a similar issue where in Windows 10 1809 (July patches) connecting to Windows Server 2019 the device tunnel disconnects as soon as the NIC detects that it is connected to the internal network.

[bdecock-minfin]

Rejoice!!! Friday 19th 10am a new fix should come out for aovpn... not the device tunnel, but frankly who is still thinking of implementing it in it’s current form?!?

The thing i just wanted to put forward is that msft is still hard at work trying to fix things.

It only took me a few months, with premier support, but we’re slowly getting there ;-)

Ben

Sent from my iPhone

On 14 Jun 2019, at 23:02, shareonline <[email protected][e-mail]> wrote:

1903 is brand new and might have issues. 1809 was fiasco all the time. My lab works great with W2019 and 1803, IKEv2.

The fix really can't be to keep our customers Windows version two releases back :)
1903 is a production build, but fair enough, 1809 should at least be more stable than 1803! If the product get's worse over time, no reason for any of us being here in this thread?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windowsserverdocs/issues/900?email_source=notifications&email_token=AJU5W26XQGI5OQOTVEY3MBDP2QBMPA5CNFSM4FCMWDVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXX6SGA#issuecomment-502262040, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJU5W26QGC4NO7VBQBXCXTDP2QBMPANCNFSM4FCMWDVA.

[cnschindler]

Thanks Ben, I guess this will be a private fix, right?

[cnschindler]

FYI:; I upgraded one of my clients to Windows 10 1903 with july patches and everything started working as expected! Would be great if those fixes could be backported...

[efbertos]

@mrhaggis

i have actually managed to have a device and user tunnel both be active at the same time for a prolonged time, this is without using trustednetworkdetection on either tunnel, and using Split tunnel on both user and device tunnels. However it is less than consistent, the coding added for the device tunnel just seems to be bugged as it works on some devices most of the time, but different devices with the EXACT same configs applied give different results. using trustednetworkdetection is just not an option as it stands as the logic for it seem hopelessly broken as it can see your network down the other tunnel. we also are testing on 1803 with the latest cumulative updates applied.

We have logged a case with Premier support, and after waiting 8 days for an engineer to be assigned yesterday, are hoping to be able to start working with them to find the bugs.

Just curious, did you ever get anywhere with Premiere support? We have had a ticket open for weeks on this exact issue with no progress or acknowledgement that there is an issue.

[mmoscheck]

I'm having the same issue as everyone else. My device tunnel is kind of finicky. It doesn't connect after a reboot a lot of time. But the big problem is when it connects, it doesn't drop after login, and the user tunnel can't connect.

This is the only thread I've found discussing this really. My guess is because the device tunnel has routes to DC's, TrustedNetworkDetection doesn't really work. The main use I want with device tunnels is for new users to be able to log into off network machines. This has to be a pretty common use case.

I'm using Server 2019 for VPN and NPS servers.
Win 10 1903 with latest patches.

[NeighborGeek]

What is the current status on this? I see a couple of mentions that this was working for some in later versions of windows, but also see others saying that it's still not working. I'm hesitant to turn on device tunnel again without someone from MS saying that this has been fixed, or at least other users here reporting that it has been working reliably for them.

[juliansiebert]

Device Tunnel broke for us with "Cumulative Update 2020-03" again. Was working quite good with 1903 and 1909 until now.
Seems in our case the per user connection cannot create routes to the same networks (with smaller metric) the device tunnel already created.

We did that to overwrite the routes created by the device tunnel with the ones of the Always On connection.

User connection errors out with reason 720 using SSTP, reason 5010 with IKEv2.

Comes at a particularly great time, as everybody is sent home during the corona outbreak...

[josh-the-tech]

Is there any update on this? We have a Device VPN and it fails to disconnect sometimes when joining the trusted network either by VPN or actually coming into the office. We have been wanting to roll this out as it'll help modernise our access and kinda needed even more now we've had to close our offices due to the outbreak.

[shortpatti]

Can a Microsoft employee PLEASE remove my name from all the documents I used to own and manage? I signed the divorce papers from Microsoft in Nov 2018 and would LOVE IT if a Microsoft writer would take ownership of the content. I don't work there, and don't get paid to correct these documents anymore. I feel sorry for the IT Professionals using these products because there's no one at Microsoft who really cares about the IT Pro :( It's obvious because these documents haven't been maintained for over 18 months.

PLEASE PLEASE PLEASE someone remove my name from these documents!!!!! I can unsubscribe until my face turns blue, but that's 100s if not 1000s of documents.

[jamesonp]

There seems to be the exact same regression with feature update 2004. Device and user tunnels cannot be connected at the same time.

If the user tunnel attempts to connect while the device tunnel is connected, they'll get the error "A connection to the remote computer could not be established, so the port used for this connection was closed."

[Jonny-WCC]

In our setup Device VPN and User VPN connects at the same time. What I've noticed is very long times sometimes which I believe is related to the Device VPN, and timing out with the domain controller for some reason or another. Anyone else get this long login times sometimes? Some people are on Login Screen for like 10-15 minutes, before they see the desktop, which I believe is some what related to the 900 second timeout.

Device tunnel only routes to DomainControllers and SCCM. IKEv2 Device Cert Auth
true
ourdomain.ad
true
false

User tunnel, only routes 10.0.0.0/8, plus few smaller networks (Split Tunnel) IKEv2 and SSTP User Cert Auth
true
ourdomain.ad
true

Both in 2004 and 1909, they both connect in our estate, we're using Intune to automatically deploy any updates, so their full up top date devices.

OS: Windows 10 Enterprise via E5 license

[Anthoniusuk]

For us the long login was about 3 minutes and was related to the Homefolder
defined on the AD user account. The login was trying to reach it, however
the device tunnel was limited to not to see anything but a few servers such
as the DC. We removed the homefolder as a quick test and then eventually
made a change to the group policy by changing the "Set maximum wait time
for the network if a user has a roaming user profile or remote home
directory".
If you really need the homefolder drive to map and do not want that server
visible from the device tunnel, you can add it as a standard mapped drive
with the username variable to group policy to avoid this issue. That way
it will appear disconnected rather than not mapping at all. Somebody else
might have a better solution though (if this is this issue you are
experiencing)

On Thu, 10 Sep 2020 at 17:00, Jonny [e-mail] wrote:

In our setup Device VPN and User VPN connects at the same time. What I've
noticed is very long times sometimes which I believe is related to the
Device VPN, and timing out with the domain controller for some reason or
another. Anyone else get this long login times sometimes? Some people are
on Login Screen for like 10-15 minutes, before they see the desktop, which
I believe is some what related to the 900 second timeout.

Device tunnel only routes to DomainControllers and SCCM. IKEv2 Device Cert
Auth
true
ourdomain.ad
true
false

User tunnel, only routes 10.0.0.0/8, plus few smaller networks (Split
Tunnel) IKEv2 and SSTP User Cert Auth
true
ourdomain.ad
true

[image: image]
https://user-images.githubusercontent.com/69788515/92757937-262ef400-f386-11ea-9b81-0174d614853c.png

Both in 2004 and 1909, they both connect in our estate, we're using Intune
to automatically deploy any updates, so their full up top date devices.

OS: Windows 10 Enterprise via E5 license

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/windowsserverdocs/issues/900#issuecomment-690400629,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL6JTQZYZPGZOEWVCT2ZXM3SFDZZTANCNFSM4FCMWDVA
.

[Jonny-WCC]

See I did think of that issue, but we added the file servers serving those network paths, to the device tunnel.

Did you add all your DCs or only the ones that the VPN subnet of AD site is on?

[Anthoniusuk]

Hi Jonny, We only added the DCs from the site hosting the VPN. Is there anything in the group policy that looks at another network location, a script or setting that may force login to wait? No unusual GINA for MFA?
Alternatively, if you set the user tunnel to not auto-connect, can you confirm that the device tunnel can reach the specified servers, just in case? I get you have likely done this already, I'm just attempting to think of other reasons why it would behave in the way you are experiencing.

[ianc911]

Coming back to revisit this two years (!) after an initial attempt to deploy this and it seems like MS hasn't really done much to make this more reliable or easier to deploy. I've just set up a 2019 RRAS server and am using a 20H2 client to test with and I still can't get the device and user tunnels to stay up concurrently. Any thoughts?

[jamesonp]

Coming back to revisit this two years (!) after an initial attempt to deploy this and it seems like MS hasn't really done much to make this more reliable or easier to deploy. I've just set up a 2019 RRAS server and am using a 20H2 client to test with and I still can't get the device and user tunnels to stay up concurrently. Any thoughts?

Try installing the KB4571744 preview. That supposedly allows the tunnels to coexist together.

https://directaccess.richardhicks.com/2020/09/07/always-on-vpn-updates-for-windows-10-2004/

[ianc911]

Thanks for the suggestion - Unfortunately that KB is only meant for build 2004 and can't be installed on build 20H2. Sigh...