Dosn't work with webvm.io #595

Closed
opened 2025-12-29 02:20:58 +01:00 by adam · 8 comments
Owner

Originally created by @lin-calvin on GitHub (Dec 13, 2023).

Bug description

dosnt work with webvm (which is built with tailscale's offical wasm library)

Environment

  • OS: Web platform
  • Headscale version: v0.22.3
  • Tailscale version: ...
  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container
headscale preauthkey create -u xxx

open webvm.io/#controlUrl=xxx&authKey=yyy in browser and the network link dosnt setup (If using tailscale's offical server, a ip will be shown)

Originally created by @lin-calvin on GitHub (Dec 13, 2023). <!-- Before posting a bug report, discuss the behaviour you are expecting with the Discord community to make sure that it is truly a bug. The issue tracker is not the place to ask for support or how to set up Headscale. Bug reports without the sufficient information will be closed. Headscale is a multinational community across the globe. Our language is English. All bug reports needs to be in English. --> ## Bug description dosnt work with webvm (which is built with tailscale's offical wasm library) <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> ## Environment <!-- Please add relevant information about your system. For example: - Version of headscale used - Version of tailscale client - OS (e.g. Linux, Mac, Cygwin, WSL, etc.) and version - Kernel version - The relevant config parameters you used - Log output --> - OS: Web platform - Headscale version: v0.22.3 - Tailscale version: ... <!-- We do not support running Headscale in a container nor behind a (reverse) proxy. If either of these are true for your environment, ask the community in Discord instead of filing a bug report. --> - [ ] Headscale is behind a (reverse) proxy - [ ] Headscale runs in a container ``` headscale preauthkey create -u xxx ``` open `webvm.io/#controlUrl=xxx&authKey=yyy` in browser and the network link dosnt setup (If using tailscale's offical server, a ip will be shown)
adam added the stalebug labels 2025-12-29 02:20:58 +01:00
adam closed this issue 2025-12-29 02:20:58 +01:00
Author
Owner

@yuri91 commented on GitHub (Dec 13, 2023):

webvm.io developer here, offering some context:

We managed to make headscale work with the wasm client in this fork: https://github.com/leaningtech/headscale

We always meant to try to upstream the changes, but it's not so simple.

In particular the main issue is that the ts2021 endpoint does not seem to work with a real websocket connection. We tried to fix it properly but with no avail.

See this commit message for more details: 038126c8b8

So our fork currently just disables the ts2021 endpoint, since if it's there, it will be tried first by the client.

There are a few more minor issues that we found and fixed in the other commits in our fork: https://github.com/juanfont/headscale/compare/main...leaningtech:headscale:main

These seem to be general issues/discrepancies compared to the official tailscale control plane that affect the time it takes to establish a proper connection.

If there is interest in upstreaming some of these changes let me know. I can also test any potential fix to the ts2021 endpoint in webvm.io if needed.

@yuri91 commented on GitHub (Dec 13, 2023): [webvm.io](https://webvm.io) developer here, offering some context: We managed to make headscale work with the wasm client in this fork: https://github.com/leaningtech/headscale We always meant to try to upstream the changes, but it's not so simple. In particular the main issue is that the ts2021 endpoint does not seem to work with a real websocket connection. We tried to fix it properly but with no avail. See this commit message for more details: https://github.com/juanfont/headscale/commit/038126c8b88e34b5fb1aedc25e1bb42cc0e5041a So our fork currently just disables the ts2021 endpoint, since if it's there, it will be tried first by the client. There are a few more minor issues that we found and fixed in the other commits in our fork: https://github.com/juanfont/headscale/compare/main...leaningtech:headscale:main These seem to be general issues/discrepancies compared to the official tailscale control plane that affect the time it takes to establish a proper connection. If there is interest in upstreaming some of these changes let me know. I can also test any potential fix to the ts2021 endpoint in webvm.io if needed.
Author
Owner

@lin-calvin commented on GitHub (Dec 14, 2023):

These seem to be general issues/discrepancies compared to the official tailscale control plane that affect the time it takes to establish a proper connection.

Is opening a PR considered?

@lin-calvin commented on GitHub (Dec 14, 2023): > These seem to be general issues/discrepancies compared to the official tailscale control plane that affect the time it takes to establish a proper connection. Is opening a PR considered?
Author
Owner

@kradalby commented on GitHub (Dec 14, 2023):

The next version of Headscale will drop support for the old non-"noise" (ts2021) protocol, so if that isnt supported, it will likely not be possible to fix.

@kradalby commented on GitHub (Dec 14, 2023): The next version of Headscale will drop support for the old non-"noise" (ts2021) protocol, so if that isnt supported, it will likely not be possible to fix.
Author
Owner

@yuri91 commented on GitHub (Dec 15, 2023):

It is supported when using the official Tailscale control plane.

A web client requests a regular websocket connection instead of upgrading the http connection to "tailscale-control-protocol". You can see the client changes they made here: a9f32656f5

I tried back then to make Headscale work with this, but as the commit that disables ts2021 says:

We tried to add support by enabling GET requests to the ts2021 endpoint,
but the connection is killed by some context cancelling before any data
is exchanged (except for the noise handshake).
Replacing a few contexts with context.Background() make it work after a
few tries, but never clean on the first try.

I haven't tried since ~ a year ago, so maybe things changed

@yuri91 commented on GitHub (Dec 15, 2023): It is supported when using the official Tailscale control plane. A web client requests a regular websocket connection instead of upgrading the http connection to "tailscale-control-protocol". You can see the client changes they made here: https://github.com/tailscale/tailscale/commit/a9f32656f53e4dbe7248852a616af75072f89000 I tried back then to make Headscale work with this, but as the commit that disables ts2021 says: > We tried to add support by enabling GET requests to the ts2021 endpoint, > but the connection is killed by some context cancelling before any data > is exchanged (except for the noise handshake). > Replacing a few contexts with context.Background() make it work after a > few tries, but never clean on the first try. I haven't tried since ~ a year ago, so maybe things changed
Author
Owner

@lin-calvin commented on GitHub (Dec 15, 2023):

webvm.io developer here, offering some context:

We managed to make headscale work with the wasm client in this fork: https://github.com/leaningtech/headscale

We always meant to try to upstream the changes, but it's not so simple.

In particular the main issue is that the ts2021 endpoint does not seem to work with a real websocket connection. We tried to fix it properly but with no avail.

See this commit message for more details: 038126c

So our fork currently just disables the ts2021 endpoint, since if it's there, it will be tried first by the client.

There are a few more minor issues that we found and fixed in the other commits in our fork: main...leaningtech:headscale:main

These seem to be general issues/discrepancies compared to the official tailscale control plane that affect the time it takes to establish a proper connection.

If there is interest in upstreaming some of these changes let me know. I can also test any potential fix to the ts2021 endpoint in webvm.io if needed.

well, this fork can just let webvm connect to headscale and get a ip, but nothing is accessable inside webvm even it self

@lin-calvin commented on GitHub (Dec 15, 2023): > [webvm.io](https://webvm.io) developer here, offering some context: > > We managed to make headscale work with the wasm client in this fork: https://github.com/leaningtech/headscale > > We always meant to try to upstream the changes, but it's not so simple. > > In particular the main issue is that the ts2021 endpoint does not seem to work with a real websocket connection. We tried to fix it properly but with no avail. > > See this commit message for more details: [038126c](https://github.com/juanfont/headscale/commit/038126c8b88e34b5fb1aedc25e1bb42cc0e5041a) > > So our fork currently just disables the ts2021 endpoint, since if it's there, it will be tried first by the client. > > There are a few more minor issues that we found and fixed in the other commits in our fork: [main...leaningtech:headscale:main](https://github.com/juanfont/headscale/compare/main...leaningtech:headscale:main) > > These seem to be general issues/discrepancies compared to the official tailscale control plane that affect the time it takes to establish a proper connection. > > If there is interest in upstreaming some of these changes let me know. I can also test any potential fix to the ts2021 endpoint in webvm.io if needed. well, this fork can just let webvm connect to headscale and get a ip, but nothing is accessable inside webvm even it self
Author
Owner

@yuri91 commented on GitHub (Dec 15, 2023):

@calvinweb please report this problem (with more details) in your existing open issue in the webvm repo: https://github.com/leaningtech/webvm/issues/93

The headscale fork does work, we have users actively using it. So maybe there is a configuration error.

I would keep this issue focused on the topic of supporting web clients in upstream Headscale.

@yuri91 commented on GitHub (Dec 15, 2023): @calvinweb please report this problem (with more details) in your existing open issue in the webvm repo: https://github.com/leaningtech/webvm/issues/93 The headscale fork does work, we have users actively using it. So maybe there is a configuration error. I would keep this issue focused on the topic of supporting web clients in upstream Headscale.
Author
Owner

@github-actions[bot] commented on GitHub (Mar 15, 2024):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Mar 15, 2024): This issue is stale because it has been open for 90 days with no activity.
Author
Owner

@github-actions[bot] commented on GitHub (Mar 23, 2024):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Mar 23, 2024): This issue was closed because it has been inactive for 14 days since being marked as stale.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#595