If you’re looking for specialized configuration scripts for Windows 10 Always On VPN, Windows Server Routing and Remote Access Service (RRAS), or DirectAccess then have a look at my GitHub page! There I’ve uploaded a few tools I’ve created (with the help of my good friend Jeff Hicks!) along with some sample ProfileXML files. Here’s a sample of what you’ll find there today.
Always On VPN
This repository includes PowerShell scripts and sample ProfileXML files used for configuring Windows 10 Always On VPN. These scripts have been adopted from those provided by Microsoft and modified to work with a separate XML file. These scripts can be used for local testing and for deploying Always On VPN connections using System Center Configuration Manager (SCCM). The ProfileXML files can be helpful for those administrators looking for real world configuration examples.
https://github.com/richardhicks/aovpn
SstpOffload
This repository includes a PowerShell script to enable TLS offload for Windows Server RRAS Secure Socket Tunneling Protocol (SSTP) VPN connections when the public SSL certificate can’t be installed on the RRAS server. TLS offload for SSTP can be enabled in scenarios where better security, performance, and scalability are desired.
https://github.com/richardhicks/sstpoffload
DirectAccess
This repository includes the PowerShell script Move-DaInboxAccountingDatabase which can be used to move the DirectAccess inbox accounting database files. The default location of the database files is on the C: drive, and many administrators have encountered disk space issues, especially in large scale deployments. This script will relocate the database files to the location of your choice.
https://github.com/richardhicks/directaccess
More to Come!
Be sure to check my GitHub site for more PowerShell script and sample files on a regular basis. Or better yet, give me a follow! I’ll be sure to post more as time goes on. In addition, I’ll be going through my older articles where I’ve provided PowerShell code samples and will include them in the repository too.
Standard Disclaimer
All the sample files and PowerShell scripts I’ve shared on GitHub are provided as-is. Although they’ve been thoroughly tested, I can’t be certain I’ve accommodated every deployment scenario. Please use caution when running these scripts on production machines.
Colin
/ January 30, 2019With the fact that device tunnels should be as restrictive as possible, it would be great to narrow down the required ports for basic communication between the device and very common systems. Active Directory, System Center Configuration Manager etc..
I don’t know if this is something you have already compiled or not Richard. If you have, It would be great if it made its way into your repo. If not, maybe another reader here has and would like to share?
There is a lot of information out there regarding these systems and the ports they require but that is the problem, there is almost too much information and some conflicting at times.
Richard M. Hicks
/ January 31, 2019Excellent idea, but not something I have done myself. There are a couple of challenges that arise when you try to do this though. First, implementing traffic filters breaks manage out. Meaning, if you enable even one traffic filter, it is no longer possible to connect to a client remotely over the Always On VPN connection. Also, creating and managing traffic filters adds significant administrator burden. There are many ports that have to be allowed, and for large organizations it might be an exceedingly difficult to accurately define them. In addition, there might be hundreds or even thousands of domain controllers to define, making the ProfileXML quite large. Finally, any time you have to make a change to a traffic filter (for example you add or remove a domain controller or SCCM server) you would have to redeploy all clients. This is where using a firewall as the VPN server is desirable. It would allow you to implement access control using a central firewall policy, and it would provide you with visibility to monitor and manage those rules. Alternatively you could place a firewall between the RRAS server and the LAN to control access. Either is a better solution than using traffic filters in my opinion. 🙂
Colin
/ February 1, 2019I totally agree. In my situation I don’t think the firewall is an immediate option but there is an immediate need for the functionality that the traffic filters offer.
Manage out with traffic filters is supposed to be fixed by Microsoft at some point. At least that is what the doc page said. Unfortunately the administrative overhead is a real life issue.
For me, I am left with dealing with it the best way I can and that is going to have to be telling SCCM to force/require an updated profile to clients. When the client checks in on an existing device tunnel, it should see that there is a new required deployment and download/install it. The script disconnects and removes the profile and then installs the updated one. I’m not thrilled about the idea but it seems to work for now.
Ideally I would move to a firewall/vpn appliance in the future but I do have a question about that. Can most of them (the fortinets and palo altos of the world) be configured to handle the certificate based authentication with your internal CA and NPS? How would you approach the setup of device and user tunnels on a third party firewall from a cryptography and authentication standpoint?
Richard M. Hicks
/ February 1, 2019Indeed, Microsoft is aware of the limitation and working on addressing it. Hoping it will be fixed in the next release. 🙂
Any firewall/VPN that supports RADIUS authentication (which should be all of them!) can perform client certificate authentication using PEAP. I’m not certain about the device tunnel though, as that’s something I don’t have any experience with. It’s on my (very long) list of things to test. Hope to have an answer for you on that in the future. That said, many solutions have their own form of “always on”, and in many cases it makes sense to go with the vendors native functionality. Cisco and Palo Alto are perfect examples. I’ve deployed Palo Alto in the past and I really like their solution. They’ve actually integrated device tunnel status in to the logon screen so you know if you’re connected prior to logging on. Very cool. 🙂
Colin
/ February 1, 2019I created this and it seems to work fine for AD/SCCM/CA and a few other services I needed.
icmp is the only thing that doesn’t work due to the apparent limitation in AOVPN.