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.

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.