I use OpenCode and the openrouter provider. From opencode I only select the model like kimi-2.6 and have no way of selecting which cloud hosting will receive my request.

Also, if you have ever used docker or virtual machines with NAT routing (often the default), you've done exactly the same things.

If you have ever enabled the wifi hotspot on an android phone also, you've done pretty much what the article describes on your phone.

All of these use the same Linux kernel features under the hood. In fact there is a good chance this message traversed more than one Linux soft router to get to your screen.

Basically it does not need dedicated hw acceleration because it can use generic vector instructions to reach similar speeds. I wonder how true that is though.

[1]: https://www.wireguard.com/known-limitations/#:~:text=WireGua...

Mistakes happen, some automation failed and the certs did not renew on time, whatever. Does not inspire confidence but we all know it happens.

But then to just instruct users to click through the warning is very poor judgement on top of poor execution.

It's a pretty well understood problem and best practices exist, not everyone implements them.

I don't get the hate/questioning on it either. It's a good balance if you want to prevent straight up cloning/stealing for profit motives while still making it open.

Seems like hardware maintainers never could agree on a standard way of exposing temperature on Linux.

These are words but they don't make sense.

Seems like this is the most probable outcome: LLM gets to fix the issues undisrupted while keeping the operator happy.

Code is always a liability. More code just means more problems. There has never been a code generating tool that was any good. If you can have a tool generate the code, it means you can write something on a higher level of abstraction that would not need that code to begin with.

AI can be used to write this better quality / higher level code. That's the interesting part to me. Not churning out massive amounts of code, that's a mistake.

The problems we had is users could not reliably tell when they were connected/disconnected, how to initiate the login flow, get network status (why is that service not working, but this other one is?), tell to which router they were connected, etc etc. I know these are big asks, and I suspect a lot of these troubleshooting and status info are probably available in the commercial offering.

That being said I think OpenZiti/NetFoundry is in a different class entirely and any lurkers here should consider it for their use. It's not really the same thing as NetBird or Tailscale.

From memory: oAuth login flow (browser based) was only supported on the windows client. For a Zero trust solution, having the only auth truly supported be a permanent JWT/Cert on the machine is doing device authentication, not user authentication, thus completely failing your primary objective.

UX was overall atrocious. Our users could not comprehend it at all. It was deemed that a custom client was required to be made.

The SDK first approach was an overall major plus point, allowing for a full customization to a specific use case.

Don't get me wrong we were overall impressed with the technology and the architecture choices. It's not a finished product, but something that does all the infra and you just need to apply the final veneer on top.

The feature set varies greatly between platforms.

If you are supporting a single platform (example desktop windows) it could work. Even better if you have the resources to write your own clients using the SDK, like it's meant to be.

Good chance it was user error on our part.

Most of their documentation is very unclear about what is a cloud offering feature and what is possible using self-hosting. There are features not available on the community edition and you have to be very careful reading their doc.

Just putting it out there so people do not think it's an easy solution. It will require appropriate planning.

I do think its a more promising solution than headscale if you want to self host as it is a complete package, unlike tailscale where you need to modify registry keys to change the cloud URL and headscale is a simplified, non-multi-tenant signaler.

If the user is forced to authenticate to start the VPN session, would that make it zero trust?

I think once the VPN is on, it's on, and the remote service cannot get identity info from the network layer.

Seems like what you want to achieve can only be built on the application layer?