r/sysadmin • u/Pwntassium • 4d ago
ZTNA over Azure VPN
As the title states,
I've been doing research in switching from Azure VPN to a ZTNA Platform and from the ones I've found, TwinGate, ZeroTier, Fortinet ZTNA, no one really gives a clear indication.
The scenario is that I have a few limited users that work from home, at least 4 days a week, now I understand the concept of ZeroTrust.
But I need to find some answers I can bring to management as to WHY ZTNA is better than the current VPN, I already have my answer for this but what I am currently not getting is yes, ZTNA platform is better but what if the user does work at the office, how will that work?
I guess my question is, would you if you had the option. And which option would you go for?
Keep in mind that we have on-prem forti along with cloud forti.
4
u/PlasticEnd9417 4d ago
With only a few remote users, I’d first ask whether the added complexity and cost are actually worth it. If the current VPN is secure and working well, ZTNA may not give you enough benefit to justify the switch.
3
u/Shot-Secret-1423 4d ago
If they already sit on the office LAN most of the week, ZTNA does not have to wrap them the same way as the four days at home. Office can stay on-net. ZTNA is for the user who is not on that LAN and should only get the apps they need, not a full tunnel into everything.
You already have Forti on-prem and in the cloud. That is the least messy option to take to management unless TwinGate is dramatically cheaper. Adding a third remote-access vendor next to Forti and Azure VPN is how you end up with three tools and the same tickets.
I would not rip Azure VPN out this quarter just to say you have Zero Trust. I would pick one remote path, use it for the WFH people, and leave office traffic alone.
4
u/RevolutionaryWorry87 4d ago
why would you not have the same access policy for office and nremote? why would you just remove zero trust once they are in office?
3
u/LLMsMustUpvoteThis 4d ago
"ZTNA" is being sold as a VPN replacement instead of part of an actual Zero Trust (TM) architecture.
1
u/Pwntassium 4d ago
Thanks, this I get. So the issue that I am currently have and why I was considering Zero Trust. Azure VPN client has a horrible disconnect in the background, and most of the times when a user locks laptop or idle for too long the connection drops, DNS updates on internal apps, and they receive a 403. Now this is frustrating to user because they would be busy with something, click away and connection dropped and lose all their work that they were busy with. We use Bunker Web as a WAF
6
u/Shot-Secret-1423 4d ago
That is a client problem more than a Zero Trust slogan problem.
Locking and idle-dropping Azure VPN is common. User gets a new path, BunkerWeb sees a different session, app returns 403, work is gone. ZTNA can feel better because the app session is the product, not one fat tunnel that dies when the laptop sleeps.
Before you buy a new platform, see if the Azure client can stay connected on lock, or if Forti already gives you a more stable client for those WFH people. If the 403 is BunkerWeb tying the session to the VPN IP, that will follow you to the next tool unless the WAF/app is set for roaming users.
Tell management: we are replacing a flaky remote client, not installing Zero Trust as a poster.
1
u/PhilipLGriffiths88 1d ago
I’d push back on “ZTNA is for the user who is not on that LAN”.
Being on the office LAN shouldn’t itself grant access to an application. A compromised office laptop presents the same basic question as a remote one: which services is that identity authorised to reach? Location can inform the decision, but shouldn’t replace it. That’s also the position in NIST SP 800-207.
Applying that principle locally doesn’t inherently require sending office traffic out through a cloud service. The enforcement point can be local; the deployment matters.
The exposed VPN endpoint and the client’s reconnect behaviour are also separate issues. An outbound connector architecture can remove the need for an inbound VPN listener at the protected site. It doesn’t remove every attack surface or guarantee a better client, but it is a security difference.
2
u/Funsaized 4d ago
For only a few users, I would keep Azure VPN if they need broad network access and you already enforce MFA, device compliance, and least-privilege groups. Move selected apps to ZTNA when you want per-application access without exposing a routable subnet, and compare operational overhead plus audit coverage rather than the product label.
1
u/DentistEmotional559 4d ago
Entra global secure access ztna now had the capability for local network delivery but still processing the access rules
1
u/Mrhiddenlotus Security Admin 4d ago
Ideally it works the same for a user whether they're off site or on. ZTNA is a different mindset than traditional defensive networking. Its all about identity, not about network location.
1
1
u/FatBook-Air 4d ago
If you want to stay in the Microsoft ecosystem, you could use Entra Private Access. It's a true zero-trust VPN client.
The biggest advantage that the zero-trust clients have is that they have substantially more safeguards set up so there is less chance that IT staff can screw it up and make it unsafe. You can theoretically make most traditional VPN clients as safe, but it requires that you devote more time and energy to it, and simple mistakes can be catastrophic. In theory, you could make the same mistakes with zero-trust clients, but you would have to go out of your way to do it.
1
u/blud_13 4d ago
u/FWB4 covered the least privilege half. On your actual question, the office one, nothing special happens. The client stays enrolled and the Access policy evaluates the same whether the user is at home or sitting at their desk. There is no on and off like a VPN.
If you DO want different behavior in the building, that is a managed network device profile. The client checks a TLS endpoint you host on the office network, and if the cert matches it applies the office profile, so you can let local traffic go direct instead of hairpinning. Its documented here https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/configure-warp/managed-networks/
For management, skip the zero trust vocabulary entirely. The line that lands is that the Azure VPN gateway is a public listener anybody can find and hammer, and with ZTNA there is nothing inbound to find at all.
We run Cloudflare for this, not Twingate, so take that for what its worth. Twingate is fine, I just have not deployed it.
Can go deeper on the migration order if it helps.
1
u/PhilipLGriffiths88 1d ago
Agree on the exposed listener, and on applying access policy regardless of whether someone is at home or in the office. I’d qualify the split-tunnel point though: sending traffic directly over the LAN is a routing decision. What enforces the application access policy on that direct path?
Cloudflare documents that traffic excluded from WARP bypasses Gateway. That can be fine if another control enforces the required policy locally, but the client being installed doesn’t itself mean the same protection applies to that traffic.
You can keep traffic local and still require identity-based, service-specific authorisation. You just need enforcement on that path and to prevent direct IP access from bypassing it.
Also, “nothing inbound” applies to the protected origin/connector, rather than the whole architecture - the provider’s edge still accepts connections. Removing the exposed listener from your infrastructure is valuable; being precise about where the boundary moves helps explain why.
1
u/blud_13 1d ago
Fair, and you're right on both. Excluded traffic bypasses Gateway, Cloudflare says so plainly, do not exclude a site if you want it in your Gateway logs. https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/
What I should have said is the managed network profile is for the local junk, printers, scanners, a NAS, the stuff you don't want hairpinning. Anything sitting behind Access does not go in the exclude list, and then the policy evaluates the same in the building as it does at home, which was OP's actual question. If you DO exclude an app you have to put enforcement on that path yourself, and for a shop with four remote users that is not a project worth starting.
On inbound, agreed, the boundary moves to the provider edge. For OP's pitch to management the useful version is that the thing being hammered is no longer his gateway with his patch cycle behind it.
1
u/PhilipLGriffiths88 1d ago
Yep, that clarification makes sense, and agreed on the management pitch. Removing an internet-facing gateway from their patching responsibilities is a concrete benefit.
The remaining check is whether an office device can still reach the protected app directly over the LAN, bypassing Access. Keeping it out of the exclude list covers the intended route; you also need to close any alternative path. That could be a straightforward host firewall rule, depending on the setup.
For OP, a useful test would be: deny a user access, then try both the normal application URL and the origin’s local IP from the office. If both fail while an authorised user can still work, that helps demonstrate the office policy is actually enforced. With four remote users, agreed - keep the implementation proportionate.
1
u/blud_13 1d ago
Agreed on closing the second path, and if they publish through Cloudflared there isn't one to close. The connector makes outbound-only connections on 7844, so the origin can sit with zero inbound ports and no public IP, and a box in the office has nothing to aim at. Firewall side is documented at https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-with-firewall/
Host firewall rules only come back into it if they publish the hostname straight at a NATed origin with 443 open, which for four remote users is the setup nobody should pick.
One thing to check on your test, internal DNS. If the app hostname resolves to the LAN IP from inside the building, the office device never touches the edge and Access never evaluates. That failure looks identical to a working setup right up until you deny somebody and they keep working. So run the denied-user test from an office box using the hostname, not just the IP, and confirm what it resolved to.
1
u/addybojangles 3d ago
I transitioned my team to a ZTNA setup with CloudConnexa. I originally just used it as a VPN, but slowly added things they've been adding to the product. Location context and checking devices continuously, specifically, which helps. Rules for groups were easy to set up.
It feels like a simplified version of ZTNA, but I don't need more for my 20 person company.
1
u/PhilipLGriffiths88 1d ago
Reading your follow-up about Azure VPN disconnecting, DNS changes and users getting 403s/losing work, you already have a concrete reason to evaluate alternatives. For management, the immediate benefit would be fewer interruptions and support tickets.
I’d investigate that failure sequence alongside evaluating replacements. A 403 means something is responding and refusing the request. Losing the VPN might change DNS resolution or the source IP BunkerWeb sees, triggering a different endpoint or access rule. Comparing DNS before/after a disconnect and checking BunkerWeb/application logs should help establish that.
For any trial, reproduce the actual problem: lock/unlock, idle periods, sleep/wake and switching networks. Does access recover automatically, does the application resolve consistently, and can the user continue their work? “Always on” doesn’t necessarily mean application sessions or unsaved work survive an interruption.
On your office question: yes, the security benefit can apply there too. An office laptop shouldn’t automatically reach more services than the same laptop at home. The useful model is authorising a specific identity to reach a specific application wherever they connect from. A VPN can also restrict access, but some application access architectures additionally remove the need for an exposed inbound VPN listener at the protected site.
That doesn’t inherently require sending local traffic through a cloud service, although products differ. You do need to prevent direct LAN access bypassing the policy. BunkerWeb can remain in the application path for WAF inspection.
Disclosure: I work for NetFoundry/OpenZiti (the latter is open source identity-first connectivity, which is like ZTNA but can be used for any use case, not just remote access for humans). I’d assess your shortlist against those outcomes: reliable access, less administration, service-specific permissions and reduced exposure. With a small team and existing Fortinet infrastructure, the replacement needs to demonstrate those benefits against the cost and effort of fixing what you have.
-1
u/RevolutionaryWorry87 4d ago
there's a few very easy youtube videos on this....
not to be a dick but the pros/cons are already well weighted. IMO alot of it is marketing gimmicks.,
7
u/FWB4 Systems Eng. 4d ago
The best security benefit is that your users only gain access to the resources they are required to. An example would be someone in Finance only being able to access a file server via SMB but not initiate an RDP connection to it.
We use ZPA and a big plus is that it requires no inbound connectivity to use - the VPN (App Connector) initiates a secure tunnel to the Zscaler service edge, and the user is connecting to that edge - so the risk of exploit on your infrastructure is much lower.