Over the last week, I've been smashing my head into a brick wall in an effort to come up with a solution to what should and for many companies would be a very simple problem. First though, some background.
ATLAS Media Group Ltd. operates as what we call a "Distributed" company, this means that we don't have an office, or a network of offices all with an internal LAN where site-to-site VPN's link those sites together. In a traditional office setup if I wanted to host an application, website or other resource that needed to only be exposed to my team, and I did not care about who can access it other than that they are staff, I'd probably host it on the LAN and give people a link to it, but that gets somewhat more complex when you're dealing with a distributed organisation.
The Problem Statement
I have a website, that needs to be accessible ONLY to ATLAS members of staff and should not be visible to the general public. The content is all entirely static and has no long term requirement to be only accessible to the ATLAS Team, and as such there is no scope to develop a custom solution to enforce some level of authentication or similar.
Our general approach to VPN's
We have always historically had a VPN Server, though it's often used more to prevent some of the lower bar to entry attacks such as man in the middle attacks over un-secured public WiFi or just for personal preference. We've historically never secured applications behind an IP Whitelist, and the VPN we originally had required manual accounts.
Our general approach is that we should be using VPN as a means to secure the traffic and to try to prevent those easier attack surfaces. We have on occasion hosted applications within the virtual network including other windows hosts that facilitate the ability to then use a stable and known workspace with a faster and more reliable broadband connection than when the team are working off-site and using a mobile hot spot.
Historically we've never had a major requirement to utilise VPN's in a large scale way and it's only ever been something a minority of the team have required.
What we've now setup
In order to enable us to protect services and endpoints behind an IP Whitelist where we are required to do so, generally in addition to authentication through our corporate Azure Active Directory, we've deployed a new VPN Service into the Superior-Networks hosting environment.
Our main requirement was that the software that was deployed needed to be easy for our team to use, and for all authentication to be handled through SSO back to Azure AD. We looked at a number of solutions, including Azure's own VPN Solution, which for the lowest tier sounded great, until they wanted an extra £120 or so to upgrade to the next tier which supported integrating with their own Azure AD Service (Which I must say baffles me to this day!).
We ended up settling on SubSpace, an open source and free piece of software that was designed with SSO in mind (And only allows auth through SAML SSO). It used the WireGuard protocol which was attractive due to its high performance and ease to setup on any platform it may be required on. Unfortunately the "Main" version of SubSpace (Github Link) doesn't appear to be maintained, so we ended up going for a "Community" version (Github Link) of it instead which is actively maintained and now has some additional features that the original one now lacks.
How we're finding SubSpace & WireGuard?
In short - So far so good!
We've been using this setup for a few weeks now and the team are really happy with what has been setup, you're able to click the button in the office.com apps screen and it'll route you straight into the application. It's trivial to add any devices on to the system and there are many configuration options. I'm writing this blog while out and about on my hotspot and connected through the VPN.
I've got my client setup on my laptop to automatically establish and mandate a connection must be established whenever I'm not on my home WiFi. This means whenever I'm out of the house and need to use my 4G Hotspot or a shared public wifi, it'll automatically establish a VPN Connection. I've also set it up to require it on Ethernet as I rarely plug that in and never at home.
There are some things that would be nice longer term in SubSpace though, the ability to view any metrics on number of active connections and bandwidth and that sort of fun stuff would be great, and having it more integrated in to the remote directory to better handle leavers for example would be ideal, at the moment if someone is marked a leaver in O365 it would prevent them from logging in to the WebUI, but as the sessions themselves aren't managed through the same Azure AD authentication they could still VPN through until a supporter goes into the Subspace admin UI and deletes their identities.
Does this actually solve our original problem?
This is another one of those solutions where it's not a silver bullet and certainly isn't going to fix all of our issues. What this has done is given us the ability to have our team and anyone we authorise access through AzureAD the ability to establish a connection and route their traffic out through our VPN.
What this does nicely solve for us is the issue where we're not able to protect an endpoint behind appropriate authentication but want to restrict access. Staff can now quickly and easily login to the VPN, download a client and connect through and ultimately access our restricted endpoint which was the end-goal for us.
Hopefully this proved to be useful and informational, if you have any questions or would like to know more about the technical services we can offer, please get in touch with us at [email protected]
