Vpn vs. zero trust

Hi everyone!

Zero-Trust sometimes seems to the word of the year and every vendor has its own definition about what it stands for… Fortinet kind of claims that zero-trust superseds VPN solutions, but I never get that. I mean if I have resources that I only can and need to access in my own network, how could I reach them safely only with a zero-trust-model?

The way to access them and to not give the whole world access to the data I have transfered is via an encrypted, secured connection - in other words a VPN. And zero-trust would say “you can only access it if your Windows runs the current patchlevel” and such stuff - but an attacker could have a fully patched Windows as well.

So I don’t get it and it seems to me that it’s more a marketing-term, but eventually you still need VPNs for the usecases mentioned above.

Please shed some light on it - thanks!

Beyond the compatibility checks that the ZTNA performs on each session, there is also a comparison of the user against your IDP. You don’t grant an access to subnets like you usually do with a VPN, but per app

You don’t need a VPN connection, you do a kind of virtual IP that verifies the user’s tags

And just as importantly it doesn’t have to be for remote connection, you can enforce ZTNA even within your network and save NAC solutions altogether

Edited : mistypo

ZeroTrust is a strategy. That means it’s up to you to define how far to take it. How do you ensure trust within your unique environment. Fortinet provides a box of tools in their firewall and VPN. It’s up to you decide which ones to use.

ZTNA is Zero Trust Neteork Access. This is a term used to define applying Zero trust principles to network access. Internal VPN is one tool used to apply this strategy. There are others such as SD Access, 802.1x, NAC, PVLAN, etc.

I HIGHLY recommend the following book/novel to everyone who is trying to get a handle on Zero Trust:

And to your point about having an attacker coming from a patched device: with ZTNA, the attacker must come from a company patched device, not just any patched device because with ZTNA, you not only do a posture check but you also allow connections if it’s coming from a corporate issued device (via PKI/certificates), so even if the credentials were compromised the attacker would not have a chance to use them because with zero trust all those checks happen prior to initiating the connection in the first place

It’s one of those times when it’s marketing but also a real thing. It’s a model/way of thinking. ZTNA is essentially proxying traffic through your FortiGate, but at much more granular level than a traditional VPN. You can check for all sorts of things like various endpoint protections, patch levels, user authentication, etc… while only allowing access to specific applications/destinations.

It’s a different model than the traditional VPN where you generally just tunnel by IP ranges. You users don’t show up as a VPN IP (they don’t even have one). It also requires a lot more overhead/management.

Definitely cautious in my response as possibly being over my skies a bit; however I have one customer who is looking at replacing the VPN with FG ZTNA, and it has been a mixed bag to date.

Accessing Apps (ie web apps) within org, not a problem. SMB shares direct to a file server…ok.
Using DFS has been challenging to say the least (not working would be more accurate). FG themselves is scratching their head (as most forum related posts). All the long-established namespaces and folder referrals are defined as FQDN (per FG June 24 KB) - we are moving to next step which is properly flag all server configs as enabledFQDN just to see if that helps.

Of course there will be other challenges: like AD password changes to sync on local workstation, possible other AD related issues (Trust). And gone would be the days of asking an end user to provide bare bone IPconfig info to eliminate some basic TS steps.

I am not sold on easier management either, as everything needs to be defined, and that can be *fun* in environments that are not as well documented/controlled/structured as they should be (which seems more the rule than not in Small-Medium business). Stating it is a good time to implement those controls is great, but without complete buy-in from the top, it goes nowhere as there is always something ‘more pressing’. It’s like trying to re-organize a file server structure (something not technically difficult but too ‘hard’ for the end users).

I actually find the tech pretty intriguing but far from sold from a practical standpoint based on what our customer base is like. Maybe when AI does a complete takeover it will all be better.

In a remote access context

A vpn uses authentication and encryption to create a secure network connection to access specified resources at the other end.

Zero trust will dynamically create tunnels to access specific resources based on authentication and other criteria. The “other criteria” is reevaluated on an interval.

So, in a fortinet world, zero trust is similar to vpn except it creates multiple vpns on the fly and transparent to the user and it evaluates more things… anti-virus running, for example. And it will shut down access if the situation changed )antivirus stopped), group membership changed.

Also, fortinet zero trust requires an EMS (web) service which is open to wherever your users are, typically the public Internet. Many would call this a security risk in and of itself.

ZT isn’t a product or feature. It’s a strategy on how you manage access and risk in your environment.

The market is generally confused because they focus on messages like “ZTNA vs. VPN”. ZTNA is not the opposite of VPN or vice versa.

Many different suppliers provide solutions to address ZTNA business requirements in lots of different ways.

You have VPN/Remote Access solutions that allow you to adopt a ZTNA strategy.
You have other solutions that allow you to adopt ZeroTrust in other ways that don’t include VPN/Remote Access.

It all comes down to what you need in the end.

If you need a VPN/Remote Access technology and would like to adopt a ZTNA strategy, then make sure you’re looking at suppliers that allow you to address your needs. If you need to route UDP traffic through the solution then consider suppliers that allow that.

There’s a /r/zerotrust subreddit with a pinned list of neutral resources, but I’ll also give a short answer here:

VPNs don’t provide zero trust. In fact, they’re specifically called out as an example of something you do not want to require.

“Remote enterprise assets should be able to access enterprise resources without needing to traverse enterprise network infrastructure first. For example, a remote subject should not be required to use a link back to the enterprise network (i.e., virtual private network [VPN]) to access services utilized by the enterprise and hosted by a public cloud provider (e.g., email).”

Why is this? Because VPNs utilize the perimeter problem, assuming that “if a user gets into the network they’ve passed all checks.” And Zero Trust absolutely does not care if a user passed the check on session-start, it wants to check continuously throughout the session, for each action, in order to ensure the user isn’t doing anything they shouldn’t be doing. Or as NIST puts it:

“It is no longer feasible to simply enforce access controls at the perimeter of the enterprise environment and assume that all subjects (e.g., end users, applications, and other non-human entities that request information from resources) within it can be trusted.”

— Line 259, Page 1, SP 1800-35b from the National Institute of Standards and Technology (NIST).

Zero trust supersedes VPN solutions because VPNs and ZTNA solutions in general lack continuous verification and context-aware access (also called out in SP 800-207 as fundamental to ZT).

VPN is like the 18 year old working at the car dealership who washes the cars and moves them around the lot. He has access to all the keys and can drive all the cars, including the $2 Million special edition Porsche Weissach 911 GT3 in PTS colors. His access is just merely that he has a badge and works there. He can drive that car all he wants until he t-bones a school bus full of kids doing 185 in a school zone.

ZTNA forces him to show his badge to security every time he goes to the key cabinet and security has been told that the lot kid only has access to the sub 30k cars and only those with 4 cylinders and are used.

TCP Access Proxy is encapsulated Traffic in Open SSL, like Forti SSLVPN. You can not use ZTNA Tags with IPsec or SSLVPN, you can use SSLVPN or IPSec addtitional to ZTNA. ZTNA use certficate based Decvice Authentication, SSL or IPSec by default User Authentication.

Well. my thoughts: Fortinet and all other vendors are just toooo lazy to patch their SSL products (and why patch it if you can sell something new, like ZTNA)… Why are so many security issues? Because its scanned and pen tested like the hell nowadays like never before… (all started with hearthbleed couple of years ago)… Wait when ipsec vpn is comming more to the attention. On the one hand it uses “SSL”, cause its a good standard. You also do trust websites with HTTPS? right?! right? [insert anakin/padme meme here]

Now to IPSEC. yeah working, but the traffic doesn’t look like anymore like SSL, (event with TCP) which can lead to problems if some starbucks or hotel wifi doesn’t allow ipsec (not just on the ports, just on the type of traffic/protocol). So with SSL mostly the traffic looks like you are accessing some secure webpage which works for almost any other starbucks/hotel internet.

Now to ZTNA… oh my god, i cannot hear that marketing bullshit anymore (throwing things together in some box and mix it together, every vendor in different ways, and then lets sell the cloud boys it with a big whoop). It works for simple stuff (http,https, and mostly known protocols). But if you need access to some specific protocol (like some SAP Connection stuff, cause the SAPGUI legacy is used, AND IT IS USED, or some “you cannot think of time tracking protocol for devices”… that will not work. So ZTNA is NOT a FULL replacement for a VPN. Hence its not a type of access, its a philosophy… (Btw, you can use ztna tags within a dialup connection (ssl/ipsec) if you have an ems). In the end ask yourself which protocol ZTNA itself uses …

Again: Ipsec over TCP… I’m not getting wet here, some extra ports? We’re in 2024/2024… thats like doing some extra protocol shit in 1998…

So imho, currently i would still stick to SSLVPN if you have the hardware (and for sure not use the latest major/minor release… who uses 7.6.0 now ???.. wait at least till patchlevel 5 or 6 or higher xD )

If you have some smaller device where SSLVPN is going be deprecated you should focus on IPSEC VPN Dialup

Sadly It would be nice if they have wireguard support… but well, than they cannot sell the ZTNA Bullshit as Access!

Written with many alcohol :wink:

VPNs provide secure tunnels for data but don’t check who is accessing what or whether they are trusted. Zero Trust Access is a model that focuses on verifying everything continuously, identity, device health, context, access controls before granting access, which limits risks if a VPN tunnel is breached. So, you might still use a VPN for securing the data in transit, but Zero Trust adds additional layers of security by ensuring only authorized access and continuous verification.

Very good and easy to understand answers.

But I might want to add that afaik you cannot use ZTNA for UDP connections like soft phones.

So if you need something like that you have to find another way and maybe use VPN just for services like that.

You don’t need a VPN connection, you do a kind of virtual IP that verifies the user’s tags

Yeah but… That means that you open your door to the public for your applications, right? Say you have an internal webserver and using ZTNA means I’d have to open port 80/443 for the whole world, right?

That’s why I like EMS Cloud with ZTNA. It’s already out in the wild with my users!

I agree—Zero Trust is more of a strategic mindset than a specific product. It’s about defining and enforcing access controls based on context and continuously verifying trust. Whether you’re using ZTNA, VPN, or another technology, the goal is the same: minimize risk by ensuring that access is granted only to those who truly need it, regardless of where they are. The key is finding solutions that fit your unique requirements while supporting a comprehensive Zero Trust approach.

A perspective to consider as I think the entire market is confused about these terms and overgeneralizes them.

VPN represents a secure way to establish a “CONNECTION” (a.k.a a Virtual Private Network). Access control is not really a part of its fundamental makeup. This may come as a shocker for some, but how do you even get to “access control” without first establishing a secure connection? Keeping it relative to what we’re discussing, of course, which is “network access” (ZT “Network Acceess”).

If you want to address secure connectivity with modern access controls then you get a solution that allows for secure connectivity (a.k.a a VPN connection) that allows you to address those access controls (e.g. a solution that allows you to adopt ZTNA).

Most suppliers out there jamming ZTNA down our collective throats start as creating secure connectivity (or a Virtual Private Network overlay). Zscaler creates the secure overlay connection (VPN connection). Netskope does. Palo does. Cato Networks does. etc., etc., etc.

If you are a remote user (even when you’re not sometimes) and you need secure access to private resources while employing ZTNA…guess what? You’re still creating a secure overlay connection (a.k.a Virtual Private Nework)!!!

Stop running away from VPN and over to ZTNA. One doesn’t exist without the other and the only differences to debate in the end is the architecture of the supplier, what traffic they actually support and their application of Security inspection.

“Does your remote access solution allow me to adopt a ZTNA strategy, support all my relevant applications and allow me to inspect the traffic the way I need to?” Who the F cares what acronyms we give the product/service in the end? To me, it’s just secure remote access the way I need it.

?? No,… you can use ZTNA Tags within the Traffic of an SSL VPN (if you have an EMS). We are doing that right now xD. Also Certificates and SAML work with SSLVPN!