Static VPN Routes not applied via Windows login screen

Question

Hi,

Can someone confirm that this commandlet works when using an '-AllUsersConnection' VPN via Windows 10 login screen?
<SNIPPET>
Foreach ($Destination in $RouteList)
{
Add-Vpnconnectionroute -Connectionname $ConnectionName -AllUserConnection -DestinationPrefix $Destination
}
*This is the Meraki VPN split tunnel script.

The routing works fine when VPN is connected during a current user's login session, and that is also true for any user that is currently logged in, yet the routes are not being applied when connected via the Remote Connections login from Windows Login screen.

Answer 1

Hi @TassieTrooper

I believe parameter -AllUserConnection does not mean its for Windows all users but Indicates that the VPN connection being modified is in the global phone book.

I would suggest put your script with login script using GPO so that It should be applied.
The path is User Configuration\Policies\Windows Settings\Scripts (Logon/Logoff).

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn789190(v=ws.11)

Also please disable Fast startup using below command

powercfg /hibernate off

Hope this answers your question :)
Thank you.

--
--If the reply is helpful, please Upvote and Accept as answer--

Answer 2

at the end of the day, it looks like the issue is device vpn profile vs user vpn profile

device vpn profile does NOT load routes. when using L2TP VPNs with 'alluserconnection', during the control-alt-delete screen when you connect to this vpn it will use a device vpn profile.
after the user profile loads, it will use a user vpn profile, and this does use (and loads) the routes.

I don't fully understand the details of how that transition works.

Microsoft said one solution is to not use L2TP. Also, PROPERLY use device VPN profiles (i.e. in your VPN architecture design) will prevent this issue. Using additional routes with L2TP vpns in the pre-logon environment (which is a device VPN profile) is not supported.
At least - this is my current understanding.

Again, here's the link I was given. This is more specific to always on VPN, but it's not ONLY for always on vpn. The info for device vs user vpn is still very relevant.
https://learn.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config

Answer 3

I disagree, not with you per se', but the function reference and usage of that parameter -AllUsersConnection as it is giving exact refence to the connection within a global users context; a connection that is available for use by all users. It seem absurd to see how this cannot not mean that and for it to only apply to the current logged in user who was active when making this entry when the command was run. Further to support my point of view, users shouldnt be able to make static routes on a PC, one for security controls, and two, we as admins use the global address book so staff dont delete nor alter them.

So back to my original quesiton, I beleive it is bugged and this commandlet with that parameter should make the routes applicable to that VPN connection for ALL users if it is in the local system global address book.

Answer 4

Hi @IT Trev

It could be, just depends if they are logging-in to their VPNs via the login page 'connections' method; alas I have posted a bug report after reading that thread you posted, as I believe it is still not fixed.

I am somewhat bemused that MSFT still haven't resolved this issue I raised, let alone not even responded to me on the side to discuss the bug.

I guess you and I are the only ones in the world that have come across it!

Cheers,

Trooper.

Answer 5

I've done additional testing.
we have carbon black endpoint on our computers, which give command line access. Using that access if I remotely start the VPN, it will connect, and services across the VPN are accessible, expect services that need the route. The vpn route is NOT injected/loaded. This can be seen using the 'route print' command.

This can also be done with psexec. If you connect with the /s option to connect as the system account, then launch the VPN, it will NOT inject the routes. Just to be clear, to launch the VPN the command is: rasdial "<vpn name>" <username> <password>.

so - this is VERY reproducible. This is either an obvious bug (now that I'm looking at it), or by design.

And again, the sequence of events:
user launches vpn from logon screen and connects to vpn (and logs on) via the vpn screen - the user does not do a 'normal logon', they click on the netwrok/vpn icon on the lower righ
vpn connect, normal logon is processed - but the network drives, mapped via gpo preference, that are on servers that need to use the routes added to the VPN time out
after logon finishes and the profile is loaded the routes are available, resources that need that route are accessible, and a manually initiated "gpupdate" will ultimately cause the drives to be mapped