I’ve been scrolling through debates of ZTNA vs VPN and most people and all vendors claim ZTNA is the superior way to access resources remotely.
I understand ZTNA in an ideal setup only allows users to access the applications they need. No one gets any access to anything unless it’s explicitly defined, hence ‘zero trust’.
My question is, aren’t most enterprise VPN solutions able to provide the same mode of access?
For example, I can set up a remote access VPN server on a Cisco/Palo Alto/Sonicwall firewall and define a VPN subnet for all users to reach to. Then I can configure firewall rules to precisely provide access to the applications the users need based on user identity and destination applications. This way, even though the users reach the remote network using VPN, they won’t have access to anything unless the firewall rule explicitly allows it, hence ‘zero trust’ as well?
If the argument is users will have unlimited access to the VPN subnet because the nature of IP routing, what if I configure the VPN DHCP server so that every user is given a /31 IP address so that they can only talk to the gateway (which is the firewall in this scenario) and not the other users?
Please share your thoughts on this topic. Why isn’t a firewall with implicit ‘deny all’ rules not considered as a zero trust solution?
Essentially you’re right. The devil’s in the details and shades though.
One nuance is that some VPN solutions either don’t have great firewall functionality, and those that do may not have them based on identity / group memberships.
The other nuance is that many “ZTNA” solutions, like Zscaler Private Access, Entra App Proxy etc., do tunnel brokering, i.e. you have connectors in your environment, and they connect to the cloud service. Your users then authenticate to the same cloud service. It checks whether the user is allowed to go to a given destination/application, and if yes, brokers the connection from the user’s outbound TLS connection to the connector’s outbound TLS connection.
The connectors can be located in multiple locations and the system can do clever routing to determine what the best connector is and whether a given connector can in fact reach the desired destination. They may also be cloud managed virtual devices, so instead of spending a night fighting with a FirePower firmware upgrade you just set an automated update schedule in the cloud portal and the connectors are automatically update with no user impact.
So yes, both solutions can achieve the same functionality, but in subtly different ways, and if the company really wants to do role-based access to specific applications with conditional access, the ZTNA solutions are more native, easier to manage and configure, and may not require a user agent with all the trouble that incurs.
My question is, aren’t most enterprise VPN solutions able to provide the same mode of access?
Yes, ZTNA is just L4 ACL on an overlay network with ABAC. Don’t get me wrong, it is the best way to share ressources, but its nothing new. If ZTNA blows you away, that means you have not yet discovered L4 ACL. The difference with ABAC and ZTNA is that I can assign the ADDS attribute to a domain controller VM, and now that VM shares the ports needed for ADDS to work via the ZTNA overlay. I can achieve the same with no overlay in a normal L2 setup with VLANs.
Zero Trust is a buzz word. L4 ACL as well as L7 rules are always used since firewalls were invented when NAT became a thing in the 1990.
My question is, aren’t most enterprise VPN solutions able to provide the same mode of access?
They are.
Identity based limited access for remote access VPN has been a thing for years.
Checkpoint for instance, a remote access VPN requires firewall rules to allow traffic out of the tunnel. This could be done in it’s own layer or as part of the main policy, you can use identity objects, application objects, traditional IP objects. Or you can limit it client side with a desktop security policy.
Traditionally remote access VPNs were setup so you could access just like you were on the LAN (hence why the client IP on Checkpoint is called “office mode”), these days it’s not the case, just like these days you segregate your lan traffic and work in the principle of least access.
ZTNA is just another marketing term for existing concepts and toolsets packaged up together. It’s all achievable with “traditional” clients and firewalls.
It’s pretty much not possible to say what’s “superior” since it’s so speculative unless you’re getting exploited enough for a controlled experiment. Just do what’s practical for you and makes people at your company happy. Most of the people making generalized pronouncements about this are either selling something, full of BS, or both.
As for the VPN subnet, the VPN client tunnels aren’t a broadcast domain. A /24 network maybe used as a pool for assigning addresses to clients, but the client won’t necessarily have a /24 netmask or any special access to other clients connected to the same VPN. Most VPNs also allow to apply firewall rules to each client tunnel that works before they would reach any other client or destination. So yeah, you can do pretty much anything with most VPN systems, as well as ZTNA. Compare them to each other individually, not as categories.
So here’s the problem with VPN and traditional Layer 4 Firewall rules is that there isn’t any way to actually prove the devices posture just from source address alone, it’s just not enough.
Sure there is identity based firewall rules, however the fundamental advantage of ZTNA is typically that it traditionally operates as a micro-segmented VPN, as well as can actually apply true conditional based access to in-line flows. This currently has not been possible with any type of ABAC or identity firewall rules.
We use Microsoft GSA and can perform conditional access prompts to secured services like SSH to network devices, RDP to jump servers and require triple factor auth + Intune compliance checks along with network proximity evaluation checks.
Simply discarding ZTNA as a VPN is a complete bastardization and anyone who argues VPN is good enough nowadays would be only looking at it from a networking lens typically.
I find ztna really annoying personally. It’s VPN with extra steps.
The appeal is that clients “aren’t on your network” because they “don’t have IP addresses”
But there’s a lot of consequences to clients not having IP addresses that you really need to think about before going in on ztna. Say your pc ops team relies on remote powershell or winrm, that no longer works and they need to find another solution
There’s no peer to peer traffic in full ztna, which breaks tools like windows update distribution optimization
Products treat DNS based rules completely differently from IP based rules so you have to separate things into different DNS domains like you separate them into different subnets, which is a lot of work if you have a flat DNS structure. Effectively have to rename every device on your network and update all the configs that reference that device, or someone is managing giant lists of names and IP addresses somehow.
I think you’re at a place in your journey where you’re beginning to see the gaps each one has. The next place you should begin looking is into SASE. You’ll find that SASE solutions recognize these gaps and work towards implementing a solution to cover them.
The mature ZTNA products provide easier management interfaces and better integration with the many other functionalities the vendors have to provide, so it is worth getting a proper ZTNA solution rather than tweaking what you’ve got.
But when it comes to the principle of ZTNA, most vendors tend to mislead the customers into thinking VPNs cannot do it by comparing with VPN products and architecture that are very old and outdated. That is the reason I got confused as to why people are claiming (modern) VPNs can’t achieve the same.
I dont fully agree with that, its only 1 interpretation and implementation. Following things like NIST 800-207, to do ZTN properly, you also need:
Access decisions to be dynamic, based on attributes like client identity, asset state, and behaviour. This means any ZTNA worth its salt needs posture checks on the endpoint.
Authentication and authorization are dynamic and enforced before access.
Further issues I would point out with enterprise VPN solutions:
Most connect ‘hosts’ or machines rather than connecting “services” and start off open by default, connecting to all hosts, rather than being deny by default. This is antihetical to the ZT concepts of least privileges as well as authentication and authorization to one resource will not automatically grant access to a different resource. Segmentation via IPs/ACLs is also more complicated and does not scale very well.
Most solutions billing themselves as ZTNA are making outbound-only connections, removing implicit trust in the WAN - i.e., external network attacks are no longer possible. The best ones do authentication/authorisation-before-connectivity so that the PEP (Policy Enforcement Point) cannot be found or connected to until you have completed authN/Z. It also removes the need for inbound ports and ACLs which is simpler to administer.
Most ZTNA solutions also implement SDN separation of control and dataplanes for higher security and scalability.
Some ZTNA solutions also allow you to do app-embedded ZTN which removes any listening ports on the underlay, making apps unattackable via conventional IP-based tooling, all conventional network threats are immediately useless. This also allows for ‘clientless’ connections as the ZTN is built into the app you use.
Some ZTNA also use the overlay to provide smart routing capabilities for further obsfucation, security, and performance improvements, as well as removing the need for things like public DNS, L4 loadbalancers etc.
TL:DR, while enterprise VPNs can do some aspects of ZTNA, the better ZTNA solutions can do many things which VPNs cannot do.
Thanks for the reply. Comparing the product individually is a good point since there’s no point to use the best ZTNA product to represent ZTNA just to compare it with a VPN solution that was implemented two decades ago. Some VPNs just can do zero trust as good as the simple ZTNA products.
Thats poorly designed ZTNA. If you correctly design a ZTNA solution you can have the benefits without the disbenefits.
You can still give clients IP addresses while being unaddressable on the underlay. You can still handle windows updates. You can use IP or DNS addresses without separating or renaming.
'Unlike VPNs, before granting access to an app or resource ZTNA verifies each user and device and performs posture checks to ensure endpoint safety. This verification process is per session, using the same access policy whether the user is accessing on-premises or through virtual cloud or public cloud resources. ZTNA reduces the attack surface by hiding business-critical applications from the internet, and it provides granular control to ensure that only authorized users can access them. ’
Palo Alto Global Protect VPN for example provides posture (HIP) checks and I’m sure many other vendor does it as well. It is very likely that this vendor itself has a VPN product that supports posture checks.
For anyone interested, I believe ZTNA solutions which do this best include NetFoundry, Twingate, Zscaler, and possibly some others. The first, NetFoundry, whom I work for, open sourced the core tech as OpenZiti.