iTranslated by AI
Differences Between ZTNA and VPN (Focusing on Microsoft Entra Private Access)
TL;DR
- I want to be able to properly explain the difference between ZTNA (LWF implementation) and VPN.
- Control at L4 is one of the key points.
- It's similar to Microsoft Entra authentication for VPN Gateway, but I feel the potential for it to be a replacement.
Introduction
As a common question, let's consider what the difference is between Zero Trust Network Access (ZTNA) and VPN.
Since ZTNA implementation methods include both VPN and LWF, it might effectively be a comparison between LWF and VPN.
I'll start by asking ChatGPT for an answer and then write my own thoughts afterward.
Please note that the ZTNA discussed here focuses on Microsoft Entra Private Access, so things might be different for Zscaler, Netskope, Cisco Secure Access, etc.
ChatGPT's Response
I asked the following question:
There seem to be VPN and NDIS Lightweight Filter (LWF) as implementation methods for ZTNA in the context of SASE. What are the benefits and advantages of an implementation using LWF?
Here is the initial response:
In the context of SASE (Secure Access Service Edge), there are VPN and NDIS Lightweight Filter (LWF) as methods to implement ZTNA (Zero Trust Network Access), but implementations using LWF offer several benefits. Here are the advantages:
Efficiency and Performance:
- LWF operates at a lower layer of the network stack, allowing it to process communications with lower latency compared to VPNs.
- Efficient traffic filtering and processing lead to improved overall network performance.
Security:
- Since LWF is integrated directly into the OS network stack, it can filter traffic at an early stage of communication. This enables early detection and blocking of unauthorized traffic.
- Applying ZTNA policies directly at the network layer strengthens endpoint security.
Flexibility:
- LWF supports multiple protocols and traffic types, making it easier to adapt to various network environments and applications.
- Dynamic policy application based on the endpoint's network connection status enables flexible access control.
Simplified Management:
- LWF is installed directly on the endpoint and is easy to manage centrally. This allows IT administrators to apply policies and change settings from a single point.
- Compared to VPNs, managing and configuring client software is simplified, reducing operational costs.
Improved User Experience:
- Instead of centrally managing all traffic like a VPN, it only filters the necessary traffic, which improves the user experience.
- Smooth access to local network resources improves productivity during remote work.
For these reasons, implementing ZTNA using LWF provides many benefits over VPN in terms of efficiency, security, and flexibility.
My Thoughts
So, here are my thoughts on this.
Low Latency
I haven't properly compared the performance here, but I think it's likely quite good. While Using the Zscaler Client Connector Windows Filter Driver mentions that "Using this filter improves interoperability between VPN clients and apps. For more information, see the Microsoft documentation on LWF drivers," the exact details are not very clear.
Using mstsc, there seems to be a slight delay before the initial authentication screen appears compared to establishing a direct VPN to on-premises, as it goes through the Secure Service Edge (SSE). However, I think this is perfectly acceptable as a trade-off for the benefits gained.
Security
Compared to the protocols used in VPNs, LWF seems to often use HTTPS. While I don't intend to compare which is more secure between IPsec and HTTPS, with Microsoft Entra Private Access, you can use Microsoft Entra Conditional Access to mandate MFA or change authentication behavior based on the source IP address. In the past, we struggled with things like installing certificates on PCs or using personal certificates to raise the identity verification level when using a VPN—it was quite a hassle. Conversely, if that level can be aligned with the same level used for accessing Azure or Microsoft 365, it would be beneficial from an auditing standpoint. Since VPN Gateway also has a Microsoft Entra authentication option, there might not be much difference in that regard alone, but LWF allows for finer control. Of course, since VPN Gateway can only be used in Azure, the ability to achieve a remote access + Microsoft Entra authentication-like setup on-premises is a major benefit.
Additionally, because the authentication destination is terminated in the cloud, there's a perspective that it's easier to handle cyberattacks targeting VPN vulnerabilities, which have been prevalent lately. Of course, Microsoft Entra Private Access won't be perfectly free of vulnerabilities forever, but it at least avoids situations like not having a maintenance contract or failing to update firmware.
Regarding the Microsoft Entra Private Access Connector, I think the fact that it doesn't require opening ports from the outside is another point that contributes to security. It only requires communication from the Microsoft Entra Private Access Connector server to the SSE, which is outbound HTTPS communication, so it feels like a lower hurdle.
Flexibility
I believe there is a clear difference here. In the case of a VPN, control is handled via routing, so the granularity is at the IP address or subnet level.
On the other hand, with ZTNA, you can control access using a combination of protocols and port numbers, allowing for much finer control.
For example, while a VPN would route the entire 192.168.11.0/24 range through the tunnel, ZTNA allows you to permit only specific traffic, such as 22/tcp or 3389/tcp, within that range.
In practice, I can't think of many cases where routing the entire range to a VPN would be a problem, but having that flexibility is certainly a good thing.
Simplified Management
One of the challenges with VPNs is that it's difficult or impossible to configure the routing on the client PC without installing a dedicated client.
Even with Azure VPN, while the IPsec tunnel itself can be connected without installing a dedicated application, in that case, the user needs to configure the routing manually.
Of course, you could just say "just install the Azure VPN client," but there's a certain peace of mind in not having the user touch this part at all.
Improved User Experience
Whether a VPN is difficult to use depends on the person, but from the perspective of Microsoft Entra Private Access, it operates transparently and seems easy for users to use.
Additionally, since administrators can check logs in the cloud, I feel it might also be easier to troubleshoot.
I plan to gather more insights on this as I increase the number of users.
Perimeter Security and Zero Trust?
In this article, I compared VPN and ZTNA as specific examples, but I think perimeter security and zero trust exist as broader concepts.
Should we compare perimeter security and zero-trust networks? also touches on this point briefly, so please take a look if you're interested.
Summary
The title suggests a common topic, and it might feel like I'm slacking off a bit since I asked ChatGPT, but I've briefly written a comparison between ZTNA (with Microsoft Entra Private Access in mind) and VPN.
While there are many similarities with Microsoft Entra authentication for Azure VPN, the ability to control communication based on protocols using LWF is one of the major differences.
I hope that Microsoft Entra Private Access Connector will eventually be provided as a managed service, similar to VPN Gateway (or perhaps provided as an .ova for on-premises).
- With ZTNA using LWF, communication can be controlled by protocol and port number rather than just by IP address or subnet.
- A remote access configuration similar to VPN Gateway + Microsoft Entra authentication can be built even for on-premises.
- No need for firmware updates like those required for VPN appliances.
- No need to open ports from the internet to the Microsoft Entra Private Access Connector server.
- Operation of the Windows Server where the Microsoft Entra Private Access Connector is installed is still required.
- You can prevent situations where users modify routing themselves to enable communication not intended by the administrator.
- Though that's a bit restrictive, isn't it?
References
- How Microsoft Entra Private Access bends packets (I didn't quite get it)
- The Exit of Microsoft Entra Private Access
- Using the Zscaler Client Connector Windows Filter Driver
- Should we compare perimeter security and zero-trust networks?
Update log
- Fixed typos, etc. - 2024/06/25
- Added tags, etc. - 2024/07/14
- Added a paragraph referring to a new article - 2024/08/08
Discussion