We currently use the Azure VPN using the OpenVPN SSL and authenticating against Azure AD along with MFA.
Although I don’t have problems with my Azure VPN with it staying connected (nor does the CEO or does most of the company going by the number of VPN tickets), my boss always claims it’s crap and he gets disconnected all the time.
With that said, my boss wants to implement the Azure Always On VPN. https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-always-on-user-tunnel
Can anybody provide me feedback on their experience using the Azure Always On VPN Tunnel? Is the experience like Direct Connect where the user is always connected to the corporate network with no user interaction? When the VPN disconnects (poor connectivity), does it automatically reconnect? If a person’s computer goes to sleep and they come back to start working again, will it reconnect automatically to the corporate network?
UPDATE: So I built a test vpn gateway with vnet to vnet peering to our production vnets. I’m using a user tunnel (since we don’t have win 10 enterprise) with a root and client certs. Everything connects as it should EXCEPT for our Azure Files. I’m unable to get the mapped drives to connect unless I use the storage account name and storage account key. I do not want to go this route as I don’t want to give users the storage account key. Anybody have any advice on how to resolve this?
Thanks
It could be totally not helpful, but I feel many networking solutions at Azure are not competitive. Look at Palo Alto Prisma Access for a more mature solution
It’s Windows 10 Always On VPN, Azure is just one possible VPN gateway, but you could host the VPN gateway yourself or use another cloud.
We use device tunnels using x.509 device certificates. We use to also have user tunnels but you need a separate VPN gateway or server because you can’t have both going to the same gateway. Anyways device tunnels are good enough. If you have PKI setup in your environment I definitely recommend certificate authentication over passwords. Besides, I’m not sure device tunnels work without them.
All VPN connections are from domain joined, corporate owned and locked down devices. The virtual network is also locked down with NSGs and host firewalls, so I’m not too concerned about unauthorized access. Besides the most likely breach point is at the endpoint under the signed on user’s credentials, so MFA or not, they are getting in, so protect your internal network.
We do split tunneling with Zscaler handling Internet access using the client, use WSUS to set which updates to install, but don’t host the updates themselves so clients go direct to Microsoft to download them. This setup saves money on gateway traffic.
Our experience with the built-in VPN client has been, good enough. The only issue is the DNS client sometimes messes up the DNS server table after waking up from sleep and requires bouncing the WiFi to make it straight.
I’ve got very good experience with Azure’s P2S VPN solution in combination with Always On VPN on Windows 10.
Instead of OpenVPN, we’re using IKEv2 with device certificates for authentication. The tunnel is started automatically on boot and will be reconnected when connections drop, reliably. Even with crappy mobile data, the VPN reconnects fast enough when coverage gets better.
UPDATE: So I built a test vpn gateway with vnet to vnet peering to our production vnets. I’m using a user tunnel (since we don’t have win 10 enterprise) with a root and client certs. Everything connects as it should EXCEPT for our Azure Files. I’m unable to get the mapped drives to connect unless I use the storage account name and storage account key. I do not want to go this route as I don’t want to give users the storage account key. Anybody have any advice on how to resolve this?
Thanks for the input!
Unfortunately we can’t use device tunnels because we don’t have Win10 Enterprise laptops. Apparently device tunnels allow you to build the tunnels before the user logs on so it makes it more like Direct Connect, correct?
But yet from a security standpoint, I agree with your points.
Thanks for the info.
It sounds like you are using device tunnels then correct? I have to use user tunnels because we don’t have win10 Enterprise.
Yes device tunnels build at computer start up so group policy can apply in the field.
But if you use Intune you can just lean on that to apply policy.
I still prefer certificates over passwords+radius for authentication, user certificates in this case, but using Intune will likely mean having to setup SCEP to issue certificates which is yet one more thing to manage.
You might want to look into the Microsoft 365 subscriptions in the future as you get Enterprise licenses with that.
Yes, that’s right. But I’d suspect user tunnels work equally good (after login). It’s the same VPN Client in the end.
Correct me if I’m wrong… if you are using client certs then there is no AAD authentication involved. Meaning if someone’s AAD password expired, they will still be able to connect through the VPN unless we revoke their computer cert, correct?
Yes, if the user’s password expired or their account was locked out or even if their account is disabled they will still be able to connect until their certificate is revoked or you add their certificate subject to the block list on the gateway.
They still wouldn’t be able to access resources on the internal network of course. You can view it as either a plus, users can change/reset their passwords themselves, or a minus, terminated employees could still access network until their certificates are revoked or added to the block list.
One other threat exists though, the ability of a user to export their certificate and private key and install it on an unauthorized device. You can make the private key not exportable though through certificate template. It’s one of the reasons we use device tunnels to prevent that because we have certificate roaming in our environment.
Bottom line though, if you have a VPN, harden your internal network, trust nobody.
Yeah good points.
thanks for the detailed input!
