So the process of deploying an Always On VPN device tunnel using
PowerShell is nearly identical to the process that we used for
deploying the user tunnel with a couple of exceptions.
First,
we do need another XML configuration file because the XML configuration
file for the device tunnel is slightly different.
So let's take a quick look at that.
(Working) So, once again,
you can find a template file for this on my website at
github.com/richardhicks in the aovpn repository,
but you could see here that this is a DeviceTunnel connection,
and the XML stipulates that, right?
So I have DeviceTunnel set to true.
This tells Windows that this is going to be a device‑based connection.
It is AlwaysOn, I have added my DnsSuffix.
In this case, I actually selected the RegisterDNS option.
You can do this on the user tunnel in XML by adding this
directive or this command or element, whatever you want to call it,
but fundamentally,
we only want to do this on the device tunnel when we're
using both device and user connections.
So here I've selected to register my IP address in the internal DNS.
I have my TrustedNetworkDetection, I've defined my VPN servers,
the native protocol for a device tunnel is IKEv2.
This is the only supported protocol for the device tunnel,
so you can only use IKEv2 here.
The Authentication method is MachineMethod,
and the MachineMethod, specifically, is a Certificate.
Also remember that we defined custom cryptography
settings for IPsec on our VPN server.
And when we set this up with Intune,
we had a nice drop‑down list where we could pull all of our values
and settings there and align that with the server.
Here we have to define that in this particular block of code,
and all of the settings, of course, need to match those defined on the server,
so use caution.
Also, you will notice, I'm going to call this out explicitly here,
the syntax differs for this particular method.
So if you're thinking GCMAES128 for the TransformConstants for both
Authentication and Cipher are the same as the EncryptionMethod,
no, the syntax changed a little bit there for some unknown reason,
and you'll discover weird things like this using the VPNv2 CSP reference.
So, make sure that you look at that document and follow it to the letter.
Anyway, so that's just an oddity for this particular setting.
We set our DHGroup and our PFsGroup and so forth,
we have SplitTunneling enabled, disabled our ClassBasedDefaultRoute,
and I defined a number of Routes.
And since this is a device‑based connection,
once again,
I'm using host routes because I just want to allow
minimal access over the device tunnel, so these are all /32s.
There are /128s, of course, for my IPv6 connections.
So, once that file has been configured, we need to,
again, run the PowerShell command in the system context,
and to do that we need a little bit of help.
So, we actually need to go out and download a tool,
one of the Sysinternals tools from the PsExec tools suite.
Enter psexec in your favorite search engine,
you should get the Windows Sysinternals reference,
so click on that.
And once you get there, we're going to download the PsTools here,
so just click on the Download PsTools link,
and then we'll click Open file.
And here, minimize this,
here what we want to do is just extract PsExec.exe to the desktop.
That's fine, that's really the only one that we need.
So once that's done, we'll run PsExec with a couple of switches,
we'll use the ‑i and ‑s switch, i for interactive,
s for system, and we'll specify powershell as the executable to launch.
I'm also going to include the ‑accepteula switch just
to get rid of some of the noise, I don't have to accept their EULA,
it'll just accept it for me if I do this.
And once that's done, we now have a new PowerShell command window.
So if we take a look at this,
we can confirm that it actually is running as system by running whoami,
and you'll see we're running as nt authority\system.
So now I'm going to navigate back to the folder where my XML file is,
and that's on the desktop for this particular user.
And you'll see that my files are all there.
So I'm going to go ahead and run the PowerShell command New‑AovpnConnection,
(Typing) and then I will specify the path to the XML
configuration file for the device tunnel,
and then I can also use the ProfileName switch here
to use a custom profile name,
but I'm just going to accept the defaults and use the default setting,
which is just Always On VPN Device Tunnel.
Also I'm going to add the DeviceTunnel switch to tell the
function to create this VPN connection as a device tunnel and
deploy it in the system context.
So there we have it.
We've got an Always On VPN Device Tunnel connection.
And now, let me show you something very interesting here,
if we go to the notification area here,
you will see that the device tunnel does not show up.
That is by design.
Don't be alarmed when you don't see it show up here.
The device tunnel, by default, does not appear in this particular interface.
It also does not show up in the VPN settings menu here,
so you will not see it here as well.
You will, however, see it in the classic Control Panel.
So this is the only place you see this.
And again, this is by design.
There is a registry hack,
there is a way to basically add a registry key to get the
device tunnel to appear in this menu.
You still cannot interact with it as a user because it is running a system,
but you can at least get the status.
So that might be helpful for you.
And you could find that information on my website.
If you go to directaccess.richardhicks.com,
search for that, I'm sure you'll find it; or use your favorite search engine, either way.