Good morning. Has anyone had success implementing always on VPN using Microsoft servers and/or Azure?
I am currently looking into this and I see how to do it using OnPrem servers for Domain joined as well as InTune/Azure for AzureAD joined computers, but we have a mixture of both.
Will I need to manage both types of computers seperately or can I do them all in AzureAD/InTune? We are in a Hybrid environment where our OnPrem AD syncs with AzureAD.
Looking for tutorials and finding them for each type but nothing explaining if you’re in a hybrid environment.
Can anyone point me in the right direction? Thanks!
Richard Hicks is kind of the go to resource on Direct Access, the precursor to AOVPN and now AOVPN. His blog is a pretty good resource. That being said, we use Direct Access at my org and I hate it and I wouldn’t think AOVPN would be any better. We’re looking at products like Zscaler’s ZPA or Palo Alto’s GlobalConnect for always on VPN solutions; I would urge you to review those before considering DA/AOVPN.
I used direct access in a previous environment. No issues as far as impacting productivity. It worked well. When I left we were testing AOVPN and they had contracted Richard Hicks for the implementation. I wasn’t on that team but I did test and attempt to be nosy. There were some issues they were working through. I think in general it was about split tunneling.
Since then I tried to implement it at 2 places. Slow moving process. I been at my new place for 6 months. I’m going try here too. So you can say I’m sold on it.
Your devices should be able to leverage single sign-on capabilities especially since since they are already known to both Azure AD and the On-prem AD. You should be able to use Intune or an RMM if you have one, for device management for both the Azure AD-joined and domain joined devices.
There is also conditional access policies which can be used with the Always on VPN to provide extra security checks if needed.
We migrated from DirectAccess to Always On VPN about six months ago, it’s been great and can’t recommend it enough. The only downside has been connectivity issues when people work off public connections where they block IKEv2 ports (500,4500UDP), this is a problem for device tunnel users as it doesn’t support SSTP like user tunnel does.
Just make sure you have a healthy PKI when implementing, I stood up a brand new two-tier CA to accommodate - moving from an ancient one.
Been using aovpn for around 3 years now with about 1000 concurrent connections. Works a treat. We push the config with Intune which is good. It mostly just works and doesn’t need much upkeep. Recently moved to kemp loadbalencer and 2 x 2022 ras vm’s behind it add some redundancy. Even more happy with it
Like some other people in this thread we had help in setting it up just so we didn’t miss anything. Also Richard hicks is the god with all things aovpn.
Vpn is still valid solution if you aren’t ready for a ZScaler solution and ztna or http proxy and if you can do per app you are better secured . There are apps you don’t want to vpn if some Remote clients can’t maintain a decent connection , may want to set minimum 20 m down to accommodate the 25% drop
Overhead if using always on .
Currently in the process of migrating from DA to AOVPN. We have both device and user tunnels deployed. Only issue I am observing is that the RAS servers just stop authenticating device tunnels after a few days and needs the RAS servers needs a reboot. I have verified that the AOVPN RAS servers only have one of our root certificates as per a Richard Hicks documentation to check. I am still investigating this issue. No issues with AOVPN user tunnels. Any help is appreciated.
Can I ask why you don’t like the AOVPN/Direct Access? Too much of a pain to maintain? Doesn’t work?
I saw another solution that is similar to what we currently have. Basic client/endpoint solution using Azure AD and you can easily leverage conditional access and MFA. Issue is getting that traffic from Azure Gateway to our OnPrem environmnet. We do have an ExpressRoute but the current vendor will be going away soon and we will need to find another way in.
Direct Access is a very bold, opinionated solution. I’d be interested in knowing exactly which parts about it that you hate.
None of Microsoft’s post-PPTP solutions have ever been viable for us because of the licensing traps, but we’re also not good candidates for a Microsoft client VPN solution for other reasons.
we actualy have a solid client/endpoint solution secured with MFA in place already, my boss just wanted me to look into Aways On VPN to see how easy it was to implement and the pros and cons. Still in the middle of that eval.
Our biggest issue with DA is simply connection problems - we have several DA clusters in multiple datacenters and the intelligence it uses to determine which one to connect to is not great. Clients will often be stuck on “Connecting…” and it never connects.
If the client’s home router is handing out IPv6 addresses it generally won’t work unless you disable IPv6 on the adapter. There is not a lot of troubleshooting data available and it’s tough to troubleshoot with the user over the phone. There isn’t really an on or off button - you can go into DA properties and disconnect or select a different cluster but it’s not obvious to users.
Other main issue is manage-out - I can’t C$ or connect to the registry on devices hanging off of DA. There is a way to configure that if you only have 1 DA server, but when clusters get involved it gets much more difficult.
The whole DA experience has me yearning for a VPN client with an connect/disconnect button that the user needs to manually kick off.
We map user’s home directories through their AD account properties and if the DA tunnel isn’t established before they login, their home drives won’t mount. They need to make sure to be connected to wifi at the login screen and wait several seconds before entering their password.
Waking the devices up from sleep often find them not connecting to DA and it requires a reboot.
Outside of Richard Hicks’ blog and some vendors, there isn’t a lot of info online about it either. I think others in this thread have posted about some custom tools or utilities that vendors have that can help - generally they’re pretty good, but you have to search for the right vendor. We had an app for instance that refused to work over the IPv6 tunnel and required a translator app form a vendor to get it work correctly.
That being said, users who don’t have issues with DA love it. When it works, it’s great. When it doesn’t work, it’s just really hard to troubleshoot. I do believe some of these things are fixed or don’t occur in AOPVN.
