PLG88

I dont disagree with any of that. I am thus thinking, I think the cleanest distinction is probably not “embedded vs not embedded”, or even “relay vs no relay”.

It is: who is supposed to control admission to the service?

Iroh seems great when the app itself wants lightweight peer connectivity: keys, protocols, NAT traversal, optional relays, and the application decides what those peers are allowed to do. That is especially attractive for local-first, ad hoc, P2P, or cross-party cases where there may not be a shared operator or prior trust relationship.

OpenZiti starts from a different assumption: there is a service owner/operator who wants to define which identities may reach which services, under which policies, with central lifecycle/revocation/routing control. In that model the controller/router fabric is not accidental ceremony; it is where the zero-trust service network is governed.

So I’d say Iroh is closer to “embed P2P connectivity into the app.” OpenZiti is closer to “embed a zero-trust service edge into the app, while the app participates in a governed overlay.”

Both are useful; they just optimize for different trust and operating models.

That said, I also dont think its useful that many in this thread are saying, more or less, 'Iroh is Tailscale at the application layer instead of the network layer'... based on my understanding of Iroh, which you have helped with, its not that at all as Tailscale also aims to provide centralised governance and orchestration.

I’d separate “app-embedded” from “no external coordination.” OpenZiti SDKs are app-embedded: the app can directly dial/bind Ziti services without a local tunnel daemon. Ziti also supports tunnelers and non-embedded options where app modification is not practical. But yes, the app is still participating in a Ziti network with controllers, routers, services and policies.

Iroh is definitely lighter-weight and developer-first, but it is not always “two binaries and nothing else” either (at least from what I have read). Once you need arbitrary peers across NATs/firewalls, you may need relays, address lookup, relay URLs/tickets, and for production likely dedicated/authenticated relays.

So to me the distinction is not “embedded vs not embedded”; both can be embedded. It is “P2P connectivity substrate” vs “governed zero-trust service overlay.” Iroh optimises for low-friction key-based peer connectivity. OpenZiti optimises for centrally governed, least-privilege service reachability, including identity lifecycle, revocation and policy control at fleet scale.

Note, I also work for NetFoundry, which develops and maintains OpenZiti.

fwiw, Tailscale happens to be mostly open source, not completely. Yes, I know Headscale exists, it does not implement all the Tailscale functions (not non-functional production type capabilities)

Glad it helped (I work on the project). Reading up on Iroh, OpenZiti approaches this less as ‘how do I reach that host across any path’ and more as ‘which identity is allowed to access which service across paths’,’ which feels like a better fit for app-specific access based on zero trust principles than a general network relay.

Good pointer. OpenZiti does fit that model well — app-embedded rather than network-wide relay/VPN first (though OpenZiti also supports non-embedded options). The main difference is it’s not just connectivity in the app, but identity- and policy-driven service access, so you get authN/Z-before-connect, with explicit Zero Trust principles, rather than just a tunnel embedded in the client/server.

Embedding is an option, but tunnelers - https://netfoundry.io/docs/openziti/reference/tunnelers/ - and edge routers (which can front legacy services without modifying them) also exist.

The difference is architectural; Tailscale is a mesh VPN, whereas OpenZiti is an identity-first, zero trust overlay network. This makes OpenZiti service-centric and deny-by-default, not network-centric. Instead of “join a private network,” you get access only to explicitly authorised services — with no ambient reachability at all. Its also 100% open source. If you want a simple productised, SaaS experience, NetFoundry, the company behind OpenZiti provides that.

That’s a fair framing, with one important distinction.

Overlay ACLs give you network-scoped microsegmentation, not service-scoped Zero Trust (as intended in NIST 800-207). You’re limiting which IPs/ports can talk after a node is attached, not deciding whether a service path exists at all per identity and per session.

The crypto isn’t the issue - WireGuard keys are strong. The issue is scope. A node identity that grants network reachability is different from a capability-scoped identity that creates only explicit service connectivity. NIST also warns that IP-based enforcement tends to reintroduce ambient trust once a device is attached. In that model, lateral movement is reduced, not eliminated.

A simple litmus test: - If authenticating gives you an IP and routes, you’ve built network trust with segmentation. - If authenticating only creates explicit service paths, you’ve built Zero Trust.

Mapping this to Wireguard and overlays, I’d say: - WireGuard + identity + ACLs = good overlay microsegmentation - Identity-first connectivity (no IP reachability, no inbound listeners) = Zero Trust by construction

If you adopt the latter, the former becomes unnecessary for Zero Trust — because identity creates connectivity directly instead of attaching nodes to a network. Bringing it back to the topic, microsegmentation manages risk inside a network. Identity-first connectivity removes the network from the trust model altogether.

Right, but if certificates are a fundamental part of your design, you should include the functional mechanisms to manage them imho (i.e., key distribution, auth/login). The developers created it, but they keep it in the commercial product. Other overlays which use PKI include those functions in the FOSS.

nah, I dont buy that. A network is not a functional requirement of SSH etc in your use case.

Fair, I was being loose with my language. What I should have said is that it does not come fully featured open source, that you need to do a certain amount of rolling your own.

Referring to the previous person's comment, that you need to manage a PKI and have to distribute the keys yourself, no auth/login etc.

Yeah, definitely more on the commercial side of the product.

And agreed, I like NetBird/Tailscale/Wireguard, but they are better VPNs, not identity-first, zero trust overlays as OpenZiti/NetFoundry is. That's why companies like Siemens have adopted it and many more will.

Ahh, I see, thanks for clarifying. That was correct, now any OIDC-compatible identity provider (Auth0, Okta, Azure/Microsoft Entra, Google, Keycloak, etc.) is supported on all the tunnelers to my knowledge.

Lots of work continues to go into the UX, but I would note that we focus most of the UI/UX work into NetFoundry, our commercial product.

How are the mobile and desktop clients incomplete?? Tunnelers exist for Windows, Android, iOS, Linux, MacOS, and more - https://netfoundry.io/docs/openziti/reference/tunnelers/....

Short answer: no, authenticating to start a VPN doesn’t make it Zero Trust.

Once you authenticate to a VPN, you’re granted network attachment. From that point on, the network is effectively saying “I trust you enough to route packets,” and enforcement shifts to IPs, subnets, and firewall rules. That’s still network-level trust, even if the login was strong.

Zero Trust (architecturally; check out NIST 800-207) changes what identity does:

- Identity doesn’t just gate entry - Identity + policy decide whether a path exists at all, per service, per session - If you’re not authorized for a service, there is literally no route, IP, or port to talk to

On your last point: it’s not “only application-layer,” but it’s also not traditional L3/4 networking. It’s an overlay where identity is bound into connection establishment itself (mTLS/E2EE, service addressing, no inbound listeners), so the network never becomes a trust plane in the first place.

That’s the difference between “authenticate, then connect to a network” and “authenticate to create connectivity.”

For a reference, check out OpenZiti, thats a project I work on - https://openziti.io/

You could use a solution that allows you to have E2E with private sovereign keys on the endpoint, as well as bring your own IdP/PKI, so the provider does not have your keys. Would that be good enough?

Out of curiosity, why? Because you dont want to run software on users devices?

Its more a sharing (outbound proxy) solution than a VPN like Netbird is.

Check out OpenZiti. Its open source, runs at prodution scale, and recently someone who used to work at Twingate said OpenZiti is many times more powerful than TG.

This problem has been brought up in the OpenZiti community many times. I like Nebula, but it's not 'truly open source'.

I like Netbird, its a better VPN, but its not zero trust networking. Zero Trust requires identity to create connectivity itself—per service, per session—rather than granting network reachability and constraining it with routes and rules. I have had this conversation on Reddit many times... curious if anyone agrees/disagrees.

Why do you think thats against the principles of zero trust? Wireguard is a wire transport, it has no control plane... I think what you are alluding to is the centralised control plane which makes it possible to operate at scale (and much more).

You have more or less described OpenZiti. Just mint a new identity/JWT for the user, create a service, and viola, only that user has access to your machine. Fully open source and self-hostable.

fwiw, ngrok started as open source

Thats why I think there will be an open source standard that other companies build their ZTNA on (i.e., similar to flavours of Linux), which supports federation, so that companies A, B, and C each have their own ZTNA, but can interoperate based on shared/agreed rules and policies. We haven't built that yet for the FOSS solution I work on (OpenZiti - https://openziti.io/), but we have heard the demand, and have it on the roadmap.

Ahh, interesting, thanks for making it clear to me. You should check out OpenZiti too, that's what zrok is built on.

I would say zrok.io is more privacy-focused, particularly with its frontdoor and private sharing features.

Sounds like what zrok.io does ... do you also support completely E2E private shares like it does - https://docs.zrok.io/docs/concepts/sharing-private/. This means the resource does not have a public IP at all (note, zrok also does public shares).

Do they? What does it do that nothing else does?

Their is tons of competition depending on how you want to attack the problem. Tailscale's problem imho is that their product does not scale well as required by large enterprises. One could argue nor do traditional VPNs, but they are already in place and workking so that product config already works, no need for change. The market is massive, but you need to be at a high abstration layer in my opinion, so that you can replace far more than just the VPN.