i want to implement ZTNA (ZERO TRUST NETWORK ACCESS) on my openwrt router. How can i achieve that ?
For the most part that is more of a policy question for your clients, than for OpenWrt itself.
OpenWrt only allows access via its access credentials and setting stricter rules (e.g. disabling http access) is easy.
1 Like
What do you mean with "ZTNA", exactly? Call me ignorant, but that looks more like a meaningless buzzword than a real thing...
2 Likes
https://thehackernews.com/2025/01/farewell-to-fallen-cybersecurity-stars.html
I found out today actually that the concept of VPN is kia, the new star is ZTNA they say.
But I haven’t really found any instruction that actually tell me how ZTNA on a tec level is supposed to work?
When reading about it, it sounds a lot like a fluffy security vision instead of any actual standardized connection technology. Or in OpenWrt terms it is simply a VPN connected to a dedicated firewall zone that control the VPN client access in the network?
1 Like
Well, it's not really a thing.
One of many high-level explanations, right from the origin I believe:
https://www.gartner.com/en/information-technology/glossary/zero-trust-network-access-ztna-
Gartner (this is pretty much not a technical description, but a visionary note):
Zero trust network access (ZTNA) is a product or service that creates an identity- and context-based, logical access boundary around an application or set of applications. The applications are hidden from discovery, and access is restricted via a trust broker to a set of named entities. The broker verifies the identity, context and policy adherence of the specified participants before allowing access and prohibits lateral movement elsewhere in the network. This removes application assets from public visibility and significantly reduces the surface area for attack.
Vs.
1 Like
My understanding is: If you're asking OpenWRT to provide you with a ZTNA, you're kind of holding it wrong right from the start Think about this easy example: My file server must not allow access only because I can route network traffic to it. I still need to have authorization mechanisms in place to prevent network intruders to access my files. Or: For how long should my file server treat requests as still having been made by me after I authenticated once? Should I be required to authenticate every 24 minutes in general? Maybe after 20 minutes of no access, maybe because I left my computer for lunch? Those examples boil down to "don't assume x only because of y". ZTNA is more or less a compliance contract, implementation according to this contract, and documentation of all the things you implemented and why they help reach what the contract wants to achieve.
If you're asking OpenWRT to just switch ZTNA on, that's, to my understanding, not, what ZTNA means.
A point you can do with OpenWRT, for example, is, not using Wireguard as VPN protocol because it only requires a certificate, but to use OpenVPN with a username, a password, a certificate file and a time-based one-time token. Reasoning: Even if someone stole my computer and somehow accessed it, he wouldn't be able to establish a VPN connection unless he stole my smartphone, too, which is the source of the one-time token. Which doesn't prevent your resources (whatever those may be, say web based intrant) from requiring credentials as well, maybe in addition to an additional OTP token to account for either your OpenWRT being broken in or someone physically plugging in his device in your office network. Which leads me to asking: If your intranet already requires an OTP, is there a benefit of OpenWRT doing this as well? In general (and moreover: Being more critical): Which role does a VPN have in my ZTNA concept, being one of potentially several transit connections and this not at all being able to control all the ways of accessing a resource?
I'd only ever ask some kind of "ZTNA endpoint" to "handle the ZTNA stuff" if
a) that service cannot be accessed other than through that endpoint (mandatory)
b) that endpoint does not handle other services (optional, advised).
So, to your question:
- Put your services in dedicated serices vlan, other than those where e.g. your wired or wifi clients live.
- Use a vlan per service, not one vlan for all services.
- If you need general and arbitrary network access, OpenVPN with the 2fa of your choice can be an option. But arbitrary network access isn't exactly ZTNA.
- SSH without shell access and very limited port-forwarding in conjunction with a 2fa could be implemented as well.
- I don't know of any dedicated ZTNA broker services that run on OpenWRT.
- The most widespread implementation would be a dedicated ZTNA broker services on a dedicated host, like e.g. Pomerium. But I don't know of any that do run on OpenWRT.
That's basically the reasoning we did at our company. We landed on Pomerium, and we require our staff to go through Pomerium, no matter if they access our services via VPN or while being at one of our offices. But there are heated discussions amongst our staff over why we cannot use the variant with SSH, deactivated shells and very limited port forwarding capabilities.
But disclaimer: We're still in the phase of rolling it out. Especially, our development staff and operations staff aren't yet switched over.
To sum it up: If you're looking for industry-established software, there's nothing OpenWRT can do for you (or at least nothing I have heard of) at the current time. Unless you're willing to define "network access" as ZTNA, that is. Which is usually not the case because that relies on trusting a routed network belongs to the account that established the route.
One year later, this still looks like a broad buzzword to me, with no known implementation that could be adapted to OpenWrt. Besides, OP seems to have lost interest in the subject. I vote to close the thread, and perhaps open a new one later, if / when somebody finally decides to implement this.
2 Likes
Common ZT tec level examples:
- Zscaler private access
- Microsoft private access (wannabe, inspired by Zscaler PA)
ZT services are like a VPN 2.0
Using classic VPN as a starting point to explain it:
- client endpoint devices have a VPN client software to tunnel access into some corporate network from outside. The user on the client gets authenticated via strong auth tokens or certs.
- A VPN concentrator endpoint acts as server-side gate keeper to the shielded corporate network.
- once passed the VPN gateway, the user has unrestricted access to the "Intranet" network
- there is a classic corporate network and a semi-holy and grumpy on-prem temple knight, eagerly guarding the 1990-inspired firewall rules.
ZT also has a client software and endpoints and basically kills the Intranet zoning ideology.
- you don't have static firewall rules for coarse grained subnets no more. Once you have passed the corporate gatekeeper, there is no more unlimited access to all services on the corporate network. Instead the authenticated user from the client device with the ZT client software has some user directory provided group permissions. Those group permissions get associated with dynamic firewall rules for that particular user and user session. a session gives you access to a single system or single service and you usually use separate ZT tunnel sessions to access different services. So it is micro segmentation combined with dynamic firewall rules.
- also due to cloud service being everywhere, ZT solutions no longer waste bandwidth on the corporate leased line (to route you inbound to the corporate network and then back out to a cloud service like MS365, instead ZT solution providers bring in a mesh of cloud-hosted ZT routing nodes (roughly similar to Onion router, but without the purpose of obfuscation). Though you can solve this via regular routing rules, the ZT solutions ensure that you have to use the ZT tunnel to additionally apply dynamic firewall rules even to cloud services that your employer uses.
- some ZT solutions offer application layer 7 firewall filtering in addition. You would need to block users via MS365 conditional access from accessing the cloud service directly, to enforce them to having to use the ZT client's tunnel.
- You can combine it with other newer products e.g. endpoint protection solutions, such that you get cut off temporarily from the ZT network e.g. if your client is detected to be infected or if your account is considered compromised, until those issues are fixed. The wanna-be-promise is that you no longer shut down the whole corporate network for weeks on infestations, but temp-cut the cord to single infected clients.
So it is roughly outlined strong auth, a VPN like tunnel solution, world wide cloud gateway routing nodes instead of a single VPN server endpoint, dynamic firewall rules and making each client and service its own firewall micro segment and linking the user account directly into each single firewall rule definition.
And that is just the ZT ideology part for legacy onprem service access. There is similar ideology to extend this idea to modern non-legacy-inspired cloud hosted services, a prominent implementation example being Entra ID conditional access policies.
This topic was automatically closed after 4 days. New replies are no longer allowed.