A while back I wrote about the various VPN protocols supported for Windows 10 Always On VPN. The two most common are Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). The article covers in detail each protocol’s advantages and disadvantages. To summarize, IKEv2 provides the best security (when configured correctly!) and SSTP is firewall-friendly ensuring ubiquitous access. Ideally an Always On VPN connection will attempt to use the more secure IKEv2 first, then fallback to SSTP only when IKEv2 is unavailable. Unfortunately, Always On VPN connections do not work this way today.
IKEv2 and SSTP
IKEv2 and SSTP are not mutually exclusive. When using Windows Routing and Remote Access Service (RRAS) as the VPN server, both protocols can be configured and enabled for VPN clients. To allow VPN clients to automatically select a protocol, the NativeProtocolType element in ProfileXML can be set to Automatic.
IKEv2 with SSTP Fallback?
In theory, with the NativeProtocolType set to Automatic, the Windows 10 client would first attempt to establish an IKEv2 connection, then fall back to SSTP if IKEv2 is not available. In practice, this is not the case.
SSTP Preferred over IKEv2
In operation, setting the NativeProtocolType to Automatic results in the Windows 10 client attempting to establish a VPN connection using SSTP first! If the SSTP connection fails, only then will IKEv2 be used. The only scenario in which I can imagine SSTP failing and IKEv2 being successful would be if SSTP is not supported by the VPN server. Sadly, this scenario may result in failed connections due to a bug in the way ProfileXML settings are processed. Details here.
VPN Strategy
The initial VPN protocol selection behavior is dictated by the VpnStrategy setting of the Always On VPN connection in the rasphone.pbk file. This file can be found under C:\Users\[username]\AppData\Roaming\Microsoft\Network\Connections\Pbk. The documentation on the Microsoft website is terribly outdated and does not include the following important VpnStrategy settings pertinent to Windows 10 Always On VPN connections.
- 5 = Only SSTP is attempted
- 6 = SSTP is attempted first
- 7 = Only IKEv2 is attempted
- 8 = IKEv2 is attempted first
- 14 = IKEv2 is attempted followed by SSTP
Always On VPN Default Behavior
For Always On VPN, when the NativeProtocolType is set to Automatic in ProfileXML, VpnStrategy is set to 6 by default, which means the connection will attempt to use SSTP first. If it fails, IKEv2 will be attempted.
If the NativeProtocolType in ProfileXML is set to IKEv2, VpnStrategy is set to 7 and only IKEv2 is used. A connection using SSTP is never attempted.
Workaround
Setting the VpnStrategy to 8 or 14 will force the client to attempt an IKEv2 connection first. However, this setting is dynamically updated by Windows and is subject to change. For example, if an IKEv2 connection fails and SSTP is successful, Windows will then set the VpnStrategy to 6 and all subsequent VPN connection attempts will use SSTP first. Because of this it will be necessary to update the VpnStrategy setting each time prior to establishing a VPN connection. This can be done using a scheduled task and my Update-Rasphone.ps1 script from GitHub.
Additional Information
Always On VPN Protocol Recommendations for Windows Server RRAS
Always On VPN IKEv2 Security Configuration
Always On VPN Certificate Requirements for IKEv2
Always On VPN IKEv2 Load Balancing with KEMP LoadMaster Load Balancer
Colin
/ January 15, 2019I imagine Microsoft will eventually address this and have Automatic work as expected. They have already said they plan on addressing the manage-out issue (really looking forward to this one bwt).. this should just be another bug fix I would imagine? Might be better to just live with it for now rather than going custom script crazy just to have Microsoft come in and change the behavior.
Richard M. Hicks
/ January 15, 2019I expect the same. No doubt many customers are complaining about this behavior. Today, my advice is to pick one protocol or the other and go with it. If you really need the additional security of IKEv2, go with that and accept that there may be some coverage gaps. You can always provide a manual VPN connection using SSTP as a backup in those cases. If you don’t need the highest level of security, SSTP is an excellent choice that still provides very good security when configured correctly, and most likely meets the security requirements for most organizations anyway. When Microsoft gets this sorted out, then enabling automatic protocol selection might make more sense. 🙂
willfulmer
/ February 6, 2019Currently using a solution using Group Policy Preferences > Windows Settings > Ini Files and levering GPP to update the line of ‘VpnStrategy’ with a value of 8.
Richard M. Hicks
/ February 9, 2019That is a fantastic idea. Thanks for sharing that tip! 🙂
Jo T
/ September 25, 2020Could you expand more on how you are doing this please? (sorry i know your comment is a year old!)
Colin Pazdzior
/ February 12, 2019Just wrote this – now for the scheduled task triggers!
—————————————————————————————-
#This script checks local user VPN strategy and overrides it – this is important as Windows
#dynamically changes and updates this, often to undesired settings.
#Get rasphone.pbk path for local user
$RASPhone = ($env:USERPROFILE) + ‘\Appdata\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk’
#Get current VPN Strategy (5=SSTP only, 6=SSTP first, then others, 7= IKEv2 only, 8=IKEv2
#first, then others, 14=IKEv2 then SSTP
$OldVPNStrategy = (Get-Content $RASPhone) -like “VpnStrategy=?”
#Set desired VPN Strategy – should be 14 for IKEv2 preferred and SSTP as fallback
$NewVPNStrategy = “VpnStrategy=14”
#Check if current VPN Strategy matches desired, end if true, continue if false
If ($OldVPNStrategy -ne $NewVPNStrategy)
{
(Get-Content $rasphone).Replace($OldVPNStrategy,$NewVPNStrategy) | Set-Content $RASPhone
}
—————————————————————————————-
Richard M. Hicks
/ February 12, 2019Another good option. Thanks for sharing! 🙂
Simon Erichstrup
/ April 8, 2020Yes, we tried this also. However, we see that ikev2 connections get established and then fail to work properly due to UDP packets being blocked or meddled with by some ISPs and/or home routers – so SSTP fallback never happens.
Shane
/ March 15, 2019I have a question regarding the setup of SSTP. I have setup a radius and RRAS server and can connect using the device tunnel using IKEv2. I am trying to setup a user tunnel using SSTP, but running into issues. Do you have any specific information on what needs to be setup on the RRAS and Radius server in order for that to work?
Thanks!
Shane
Richard M. Hicks
/ March 15, 2019Try this: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-nps. 🙂
David Kafrissen
/ July 26, 2019HI
We are looking to migrate from our DA server to Always on Server.
We were going to use the existing DA server, but this doesn’t look like we can as the current RRAS security setting for Authentication is on Windows Auth and not Radius.
From following along on the MS site they want Radius.
Should I just build a new server and point to the existing NPS server (also the DA server)?
Thanks
David
Richard M. Hicks
/ July 26, 2019It’s a good idea to separate VPN and DirectAccess anyway, so I’d suggest going that route. It will make your life much easier in the end. 🙂
Luke Flack
/ August 5, 2019Hi Richard,
I have specified the excryption settings in the CryptographySuite eliment of the ProfileXML, and on the server. When I set the NativeProtocolType to IKEv2 it connects fine.
When I set the NativeProtocolType to Automatic I find that SSTP works fine but the encryption settings in ProfileXML do not seem to apply for IKEv2.
When I set the VpnStrategy to 8 or 14 IKEv2 always fails and moves on to SSTP. If I set the VpnStrategy to 7 (IKEv2 only) it will not connect at all giving me a Policy match error.
I have run a network trace and I can see that the old default 3DES is being presented by the client.
The only difference in the ProfileXML is changing the NativeProtocolType from IKEv2 to Automatic.
Is this a bug? I’m running Windows 1709 at the moment.
Thanks,
Luke
Richard M. Hicks
/ August 5, 2019This is a bug that Microsoft is aware of, but I’m not sure if they are actively working to address it. Essentially if you import ProfileXML with custom cryptography settings and the native protocol type set to “automatic”, the custom cryptography settings get imported incorrectly. This will result in SSTP working but IKEv2 failing with policy mismatch errors. The only workaround at this time is to set the native protocol type to “IKEv2”, and then change to automatic later by updating the entry in rasphone.pbk using PowerShell, group policy preferences, or something else.
James Hawksworth
/ May 28, 2020This still appears to be the case on Win10 1909, just trying to get SSTP fallback to work and IKEv2 keeps failing, where it works fine by itself.
Your workaround still works at least, so many thanks!
Richard M. Hicks
/ May 29, 2020Good to know!
Chris
/ September 12, 2019Just a quick question regarding IKEv2 and SSTP Fallback with a LoadBalancer like Netscaler in Front.
I guess then I need to Offload SSL on the Netscaler because I need to configure the VIP to listen to UDP 500 / 4500 (IKEv2) and TCP 443 (HTTPS). I cannot use SSL Bridge and IKE on the same VIP.
Is this correct?
Richard M. Hicks
/ September 12, 2019I’m not aware of any limitations like that. I’ve configured other load balancers using multiple ports on the same VIP without issue (Kemp, F5, etc.). Expect the same would hold true for NetScaler too. Shouldn’t have to offload TLS in that scenario.
Dietmar
/ September 23, 2019Today I created a workaround for 3 problems we came across: multi-user support of AlwaysOn VPN user tunnel (auto-trigger), VPN strategy set to 14 and the missing IPSec settings in the rasphone.pbk (which is a Microsoft confirmed behavior if the native protocol type is set to Automatic. You can save the PowerShell-Script (the one you use for ConfigMgr deployment) to a folder which the user cannot modify. Then create a schedulded task, run it every time a user logs on, and in SYSTEM context. With this config every user who logs on gets the profile every time installed (very handy, stable and fast). That way the RasMan service is proper configured to auto-trigger the connection, it’s seemless to the users and… it works! Additionally I added the following lines to the script
#######################################
# Workaround for missing VPN settings
#######################################
$Benutzer = ($objuser.value).ToString()
$Benutzer = ($Benutzer.Split(“\”))[1]
(Get-Content -Path “C:\Users\$Benutzer\AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk”) | `
ForEach-Object {$_ -replace ‘VPNStrategy=.*’, ‘VPNStrategy=14’} | `
ForEach-Object {$_ -replace ‘NumCustomPolicy=.*’, “NumCustomPolicy=1 `r`nCustomIPSecPolicies=020000000200000003000000030000000200000003000000”} | `
Set-Content -Path “C:\Users\$Benutzer\AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk” -Force
Restart-Service RasMan -Force
These lines correct the VPNStrategy to 14 every time a user logs on, corrects NumCustomPolicy to 1 and add a line CustomIPSecPolicies with the IPSec settings.
This works like a charm for us. Now we are ready to deploy AlwaysOn VPN.
Cheers, Dietmar
Richard M. Hicks
/ October 7, 2019Awesome. Thanks for sharing! 🙂
Daniel
/ October 28, 2019I do not know if anyone had the same experiences, but we had different problems with Always-On-VPN (such as trusted network detection sometimes didn’t work, random disconnects during the day or an unstable connection) but since we’re not using VPNStrategy 14 anymore, the problems are all gone so far. With VPNStrategy 7 everything works much better! Maybe Microsoft is not supporting VPNStrategy 14 anymore and is doing bugfixes only with the “GUI-visible” connection modes? However, just wanted to share this experience if somebody has similar issues. We used a scheduled task to check the setting in the rasphone file.
Greetz Daniel
Richard M. Hicks
/ October 28, 2019Thanks for the feedback! No question Always On VPN seems to be more reliable when you choose a single transport. Hoping that Microsoft addresses the persistency issue with the VpnStrategy setting in the future for sure.
Tom Klaver
/ December 10, 2019One small tip when you create a task by SCCM in Task Schedule to run the Always On VPN Profile script during a user logon to update VPNStrategy setting. Don’t forget to add the option $Settings=New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries. Otherwise the task is not executed when the machine is on battery 🙂
$Location=$PSScriptRoot + ‘\VPN_Profile.ps1’
if (! (test-path -Path C:\AlwaysOnVPN) -eq ‘False’)
{
New-Item -Path C:\ -Name AlwaysOnVPN -ItemType Directory -Force
}
Copy-Item -Path $Location -Destination C:\AlwaysOnVPN -Force
$Trigger=New-ScheduledTaskTrigger -AtLogOn
$User= “NT AUTHORITY\SYSTEM” # Specify the account to run the script
$Settings=New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries
$Action= New-ScheduledTaskAction -Execute “PowerShell.exe” -Argument “-ExecutionPolicy ByPass -NoProfile -File C:\AlwaysOnVPN\VPN_Profile.ps1” #Specify what program to run and with its parameters
Register-ScheduledTask -TaskName “Always On VPN Configuration” -Trigger $Trigger -User $User -Action $Action -Settings $Settings –Force # Specify the name of the task
Robin
/ February 14, 2020Hello Richard,
Any news on this, do we still have to change the VpnStrategy value all the time, or can we have IKEv2 as default?
Richard M. Hicks
/ February 14, 2020The fix is supposed to be included in 1903/1909 but it hasn’t worked in my testing. Once I get it sorted out I’ll definitely post something.
Johan
/ December 10, 2020Hey Richard! Have you been able to confirm if anything has changed with 1909?
Richard M. Hicks
/ December 17, 2020I’ve been told this has been fixed, I just haven’t had time to test it. Watch for a blog post early next year on this. 🙂
Simon Erichstrup
/ February 25, 2020Hi Richard,
First off, thank you for all your great articles on this subject.
I am running Device Tunnels with ikev2 and continously run into ISPs medling with the UDP packets rendering my VPN solution disfunctional.
I read your articel and enabled SSTP but clients now simply get a prompt for username and password.
After some digging I realize device tunneling and SSTP does not work together 😦
What are my options?
User Tunnelling is of course a way to go, but I would rather not go that way.
Can I alter my setup in some way to make the device certs usable as authentication through SSTP through a tweak, fix or revert back to a Dial-In VPN perhaps?
Any insights would be helpfull.
Richard M. Hicks
/ February 26, 2020Indeed, the device tunnel uses IKEv2 exclusively. There is not support on the device tunnel for the SSTP protocol today, unfortunately. I’m not aware of any native options for establishing a device tunnel using SSTP. However, there may be other ways to hack something together. It’s not something I’ve tried, but it would be an interesting experiment for sure. I’ll add it to my list of things to investigate and let you know what I find. 🙂
Simon Erichstrup
/ February 26, 2020Hi again,
Thanks for your respons.
I hope to find some time to play with this as well
Regards Simon
Maurice
/ March 30, 2020Hi Richard,
Would it be possible to setup an IKEv2 Device Tunnel and fall back to an SSTP user tunnel if IKEv2 is failing?
Richard M. Hicks
/ March 30, 2020No. The device tunnel requires IKEv2 and uses it exclusively. There’s currently no support for SSTP on the device tunnel at the moment.
Shane
/ April 8, 2020I understand that SSTP is not supported on a device tunnel. Can you fall back to SSTP user tunnel if the primary connection is a configured with an IKEv2 Device tunnel? Is it not possible to setup a device tunnel and a user tunnel?
Richard M. Hicks
/ April 8, 2020You can definitely set up both device tunnel and user tunnel, that’s quite common. It wouldn’t failover, necessarily. They are two independent connections. If you configure the user tunnel with SSTP, it will always connect regardless if device tunnel was successful or not.
Simon Erichstrup
/ April 8, 2020Yeah, this is the biggest caveat for me as well. We have implemented User Certs as a “back up” solution for this reason (ikev2 udp traffic being blocked by several ISPs and home routers/firewalls)
However, we need the device tunnelling to ensure pre-logon connectivity and you cannot accomplish this with User tunnelling (afaik).
I hope MS would consider an option with device tunnelling over SSTP.
Richard M. Hicks
/ April 8, 2020No doubt many have asked for this feature. 🙂
Aftaab
/ April 16, 2020Hi Richard, great articles as usual. So you pretty much hijacked all top results in Google keywords for Always On VPN 🙂 .
Do you know if there are any hard limits for SSTP number of ports on RRAS when you set it up in Windows Server 2016/2019? Default for SSTP and others seem to be 128 for most protocols but i can’t see any good documentation for guidance. We have IKEv2 as 1024 ports and SSTP as 128 ports with Automatic fallback but looking to bump those numbers of ports just in case but unsure of impact. Our userbase is circa 500 and we have forced tunnelling so users drop their device tunnel when connecting to user tunnel and with SSTP fallback.
Richard M. Hicks
/ April 17, 2020I would use the word “achieved” instead of “hijacked”. 😉 To answer your question, no, there’s no hard limit on the number of VPN ports you can configure in RRAS (that I’m aware of). I’ve set this as high as 8,000 before without issue. In fact, I just tested now and set both to 12,000. I can’t imagine anyone need more ports than that though. 🙂
Matt
/ June 25, 2020If the a device tunnel is urgently required for some reason, (such as for a user password reset) and IKEv2 connectivity is not available on the local wifi, do you know if the major cellular tethering hotspots in the US such as AT&T, Verizon and T-Mobile support IKEv2 tunneling?
Starbucks wifi?
Richard M. Hicks
/ June 29, 2020Very few ISPs block IKEv2. It’s mostly blocked (or more accurately, not allowed by default) by hotels and corporate guest networks. Coffee shops seem to be reliably open in my experience.
Jeremy Noone
/ July 6, 2020Hey Richard,
Thanks for the articles. I keep thinking I’ve got our VPN ready for production but run into another issue that you’ve seemed to have covered, documented, and shared.
You mentioned security of SSTP vs IKEv2. Aside from an argument for closed vs open source, and SSL 3.0 potential vulnerabilities, I can’t find an articulate or factual argument against it. Do you have any other info?
Richard M. Hicks
/ July 7, 2020There are advantages and disadvantages for using either IKEv2 or SSTP. I feel personally that SSTP is acceptable for most deployments and provides more than enough security when properly configured and optimized. Of course IKEv2 provides the best security options, but has it’s own limitations which I’ve written about here: https://directaccess.richardhicks.com/2019/04/15/always-on-vpn-ikev2-features-and-limitations/.
John
/ July 20, 2020Hi Richard,
We are currently using VPN strategy 14 , however have seen some issues, with connections.
As alluded to above in the comments is 14 still supported?
The MS docs don’t seem to reference 5, 6 , 8 and 14:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rrasm/7574fc0f-3e82-4b69-a4c3-43b588fad4d7?redirectedfrom=MSDN
Thanks
Richard M. Hicks
/ July 21, 2020Yes, VPN strategy 14 is indeed supported. Sadly, the Microsoft documentation is terribly outdated and doesn’t include this information.
victor bassey
/ September 29, 2020Is it possible to have a configuration as follows:
Device Tunnel – IKEv2
User Tunnel – SSTP
Both Tunnel uses split tunneling
I currently have a client who has deployed device tunnel (only) with IKev2 but a considerable number of users keep getting issues with their home routers. I found with some, enabling UDP port clamping on their home router sometimes help with stabilizing the connectivity, but others still have issues.
I was thinking of implementing a user tunnel (SSTP) on top of the existing device tunnel if this will help minimize the connectivity issues experienced with just the device IKEv2 based tunnel.
Richard M. Hicks
/ September 30, 2020Absolutely. This is the most common deployment scenario in fact. 🙂
victor bassey
/ September 30, 2020Great! Thanks Richard for the pointer.
Benj
/ October 28, 2020Hi Richard, thanks for you brilliant articles on VPN/DirectAccess.
Just a heads up:
After communications with Premier Support I was made aware of that you can add a registry key to disable Windows updating the VPNstrategy:
reg add HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters /v VPNStrategyUsageDisabled /t REG_DWORD /d 1 /f
OS also needs to be updated past these for the regkey to work:
RS4 (v1803) fixed in https://support.microsoft.com/en-us/help/4534308/windows-10-update-kb4534308
RS5 (v1809) fixed in https://support.microsoft.com/en-us/help/4534321/windows-10-update-kb4534321
19H1 (v1903) fixed in https://support.microsoft.com/en-us/help/4517211/windows-10-update-kb4517211
Richard M. Hicks
/ October 28, 2020Thanks for the update! I was told by Microsoft support quite a while ago that this was fixed, but when I tested it still didn’t work.
Have you tested and confirmed operation?
Benj
/ October 29, 2020This is confirmed working in 1809 with latest october patches.<
Support guy mentioned 1909 and later would not need any patch for the regkey to work.
Richard M. Hicks
/ November 1, 2020Good to know!
Sean
/ November 9, 2020I am finding that with this setup though if deployed via intune the next check in it blows out any modifications to VPNStrategy and as a bonus it also disconnects as well
If I deploy the profile manually then this key prevents windows from overriding it arbitrarily. I have opened a case to push this as the vpnv2 csp and this particular option are woefully inadequate. I am also pushing the security angle as a mitm could block your sstp and ike attempts, and then your throwing trivially reversible protocols in the mix (Automatic = SSTP, IKEv2, PPTP and then L2TP, as per https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp) with potential mfa type tokens accessible if using the conditional access extensions.
Richard M. Hicks
/ November 9, 2020Thanks for the heads-up! Not sure I ever tested this using Intune provisioning. Good to know it works differently than SCCM/MEMCM deployments. No doubt not being able to specify the exact protocol you want to use, and in which order, is limiting. And with no option to choose SSTP explicitly, using “Automatic” does present a problem by allowing PPTP to be accepted.
That said, Microsoft has supposedly fixed this with a registry entry that prevents overwriting the VpnStrategy setting if the administrator changes it. However, I don’t know if this solves your problem with Intune overwriting the entire profile and wiping out that setting. I’ll do some testing and see what I can learn.
Sean
/ November 12, 2020There is a lot broken it seems. I can’t seem to specify the element and have it apply when using nativeprotocoltype automatic. Intune it doesn’t deploy at all (if I remember correctly during our deployment back in April it just errors), via the WMI bridge it will apply but if you look at the IPSecCustomPolicy its blank. I can then patch up the crypto with powershell and it works as intended. I am at a loss, every time I want to optimize Always On I have to give up to keep my sanity 😛 Seems if I had done a full powershell deployment I could have hit all objectives…
Richard M. Hicks
/ November 17, 2020I feel your pain. 🙂
Sean
/ November 12, 2020Also that Microsoft openspec doc about VPNStrategy changed quite recently and doesn’t show half the operable options anymore. The undocumented options still work, just seems that they are being scrubbed 😛
Richard M. Hicks
/ November 17, 2020Very strange indeed!
Justin
/ November 4, 2020Hi Richard, thanks for another great post! Is it possible to set SSTP only in the script without having to use the Automatic tag? I don’t want to use IkeV2 at all as it has been blocked by too many users’ home routers.
Richard M. Hicks
/ November 6, 2020No, the CSP does not include SSTP as a dedicated protocol type unfortunately. The workaround for this is to push out the profile as Automatic, then update VpnStrategy to 6 after deployment using my PowerShell script: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
Justin
/ November 10, 2020Awesome thank you 🙂
Marko Z
/ December 10, 2020Hello,
can you please write the latest and the best solution for all the problems mentioned in this comments? I’m a bit confused 🙂 Also, how should I configure the scheduled task (which command to run and which arguments) and where is the best place to put the script?
Also, what is the best solution to deploy AlwaysOn VPN profile (with the generated ps1 script). Group Policy, PDQ? Any other way? Under which user deploy script should be run?
Thank you!
Richard M. Hicks
/ December 17, 2020Microsoft has addressed this issue and I’ll be publishing something on it soon. As for Always On VPN profile deployment, the best option is to use Intune. Outside of that, you can use whatever you like (SCCM, PDQ, Active Directory and group policy, etc.).
kjn
/ December 12, 2020What happens if the user tunnel is configured to multiple user profiles at the same machine?
Richard M. Hicks
/ December 17, 2020You can deploy an Always On VPN profile to more than one user on the same machine, but only ONE user (the last one configured) will automatically start. No workaround if you are using Intune, unfortunately. If you are using SCCM or something else, use my PowerShell script with the -AllUserConnection switch and deploy the profile for all users. Here’s a link to my script: https://github.com/richardhicks/aovpn/blob/master/New-AovpnConnection.ps1.
kjn
/ December 21, 2020Thanks! Is “allusersconnection” different thing than device tunnel?
Richard M. Hicks
/ December 22, 2020The -AllUserConnection parameter on my script creates the user tunnel in the context of “all users”, making it available for anyone who logs on to the device. It is still a user tunnel, however. A device tunnel is technically also deployed to all users, but it uses a different OMA URI.
Marko Zaletel
/ December 29, 2020Hello,
I have found another problem. When client connects using Always On VPN, DNS registration happens but the problem is that also user’s local private address gets registered in company DNS, not only Always ON adapter. How can I solve this?
Thank you!
Richard M. Hicks
/ January 6, 2021Try setting the following registry key and let me know if that helps.
HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DisableNRPTForAdapterRegistration DWORD = 0