Introducing srv-headscale

Because my last contrib went over SO well :smirk_cat: , I’m back :hugs: for more vapid :roll_eyes: criticism :grimacing: !? :person_shrugging:

Use case:

Have you had the need to connect disparate systems (IE: home LAN, hosted pentest labs, Quake LAN party, C2 3v!1 etc.) but, can’t be arsed to fuss with firewall rules? If so, maybe this solution can ease your pain?!

Here is a simple SaltStack solution:


(This is the naming convention I use but, feel free to go wild with sed/vi/nano/GUI to rename to your liking.)


Source is minimal & concise for practitioners but, I’ll try to provide a high level overview for those who don’t know how to read and/or understand SaltStack.

  1. A debian based template (TemplateVM) is created (srv-headscale-template)

  2. An open source, self-hosted implementation of the Tailscale control server (headscale) is served via a Cloudflare Tunnel client (formerly Argo Tunnel) (cloudflared) with a web frontend for the headscale Tailscale-compatible coordination server (Headscale-UI) served locally via a fast and extensible multi-platform HTTP/1-2-3 web server (caddy) which are all installed in the TemplateVM created (1)

  3. A disposable template (AppVM) is created based on the aforementioned (1) template (srv-headscale-dvm)

  4. A named-disposable VM (DispVM) is created from the disposable template in (3) (srv-headscale)



In srv-headscale:

  1. Create client string for use with Tailscale


In srv-headscale:

  1. Create API key (necessary for GUI use)
sudo headscale api create
  1. Browse to “http://localhost/web/settings.html” with Falkon browser

  2. Populate “Headscale URL” (http://localhost) & “Headscale API Key” (from above) + Click “Save API Key” Button

  3. Manage Users & Devices


All of the components work well on debian-11-minimal aka bullseye. However, a working debian-12-minimal template MUST be used to deploy via these salt formulae.


That sounds overly complicated?
Why make salt formulae that require a non default template?

What purpose does the cloudflare tunnel serve there?
Is it using cloudflare infra?

Does it break boundary assumptions in qubes?

It does not sound attractive enough to actually invest the time read what you are doing.
Explain harder to convice me to join the mindshare or something

Ok I read anyways.

  • You are downloading unauthenticated software.
    • You import a cloudflare signing key by just fetching from an url instead of strongly referencing or adding the pubkey itself.
    • You are pip downloading python packages, which are unauthenticated.
      ( I consider the web PKI alone, not combined to hashes, to be equivalent to unauthenticated and “trusting the infrastructure”. )
  • Its not readily apparent what cloudflare is used for here. What use has headscale which is expressly selfhosted if it was proxied via a third party network?
    Is it hosted via third party? If not, please make that clearer to see.
  • I dont continue reading it because it makes no conceptual sense to me.

To you.

If you actually used salt formulae, maybe you’d know.

It’s quite obvious.

Know what “they” say about assumptions …

Nor do you seem to have the technical aptitude so, I can’t be bothered.

I see you’ve edited your original post so, I guess I can respond to some of your now quasi-informed presumptions … sigh

A) It’s using code from github, it’s ALL “unauthenticated software” :joy: :upside_down_face: :smirk:

B) Those modules become ephemeral anyway as they are installed to /usr/local but, you knew that right? :melting_face:
(I’ll probably do away with the pip stuff (lastversion isn’t needed as it was when I began the work) so, thanks for the paper tiger whining :+1:)

C) Cloudflared aka argo tunnel offers an “up and running” public URL/IP to work with w/o any need for user interaction/API key/sign-up

  • Signing key can easily be validated via user preference (key server/signing party/carrier pidgeon) post install

  • Any adept user can easily modify the formula to use one’s own domain/DDNS

D) I’m open to suggestions regarding keys, so long as it’s are on par with gpg --recv-keys which, doesn’t “just work” in TemplateVMs

E) headscale/tailscale is mesh-VPN brahhski, encryption happens between the clients (even after the sys-headscale is powered off)

Ah you are one of those people that consider any criticism as FUD and everyone to be too dumb. And everyone to be insincere if they dont bother to respond to every one of their half sentences. But for themselves it is ok to do blanket statements.

I hereby stop interacting with you and consider youna bite reflex person. Have a good day

I welcome informed critique but, your post is just more of the same ignorant psuedo-paranoia as seen posted with my last contrib, a n00b derailing due to ignorance w/o diligence with the only thing added to the “discussion” being personal feelings.

1 Like
Reminder about edits and mailing list users

@LongIslandIceTea, @cayce please keep in mind that some users interface with the forum through a mailing list interface and can’t see any edits done 10 minutes or later after the original post. In those cases new posts are preferable.

@LongIslandIceTea's edit
@cayce's edit
1 Like

Thanks for the reminder and the refresh for the mail-list :+1:

1 Like
Moved to `General discussion`

Moved to General Discussion since there is no User Support issue to be solved but rather a contribution to be discussed. I sincerely hope this thread is a lot more technical (adversarial thinking is expected and appreciated).


Forum stuffs

Can delete this after you’ve read.
Yeah, I don’t know where to post contribs … forum sections are lacking IMO. Would be great if there was a “dev” corner section or something of the like.

@cayce is there any chance you could provide 2 or 3 use cases in non-technical terms for sys-headscale?


  • PROBLEM: The issue at hand
  • SOLUTION: How it solves the issue
  • WHY IT’S BETTER: What it does better than other solutions

Not suggesting that these can’t easily be answered or anything. It’s just that I think more people would see the benefit in your work if they had a few use cases in front of them.

Like, I can see people potentially erroneously thinking this would be used between qubes on the same machine. I mean, sure, I guess you could if you wanted to, but I’m not sure that’s what you had in mind when you came up with this idea :stuck_out_tongue:

In any case, I can see that you’ve put effort into this, and I don’t want it to go to waste :slight_smile:

DISCLAIMER: I believe the Qubes contrib repo (or a separate contrib-untested) needs a few more packages in it, showing more functionality of Qubes OS, and this (along with your other contributions) may well be one of those packages :slight_smile:

Edit Notification

Edited post to reflect renamed project from sys-headscalesrv-headscale.

I’m a bit confused by your request … this post literally begins with a section titled “Use case”. Are you unable to see this for some reason?

:rofl: @ the idea of the Qubes contrib repo as, it’s always looked to be abandoned to me. Appears to be nothing more than a showcase for dom0 “toy” projects made by the Qubes team.

What you wrote doesn’t actually tell me that much, to be honest, and I was looking for a little more information.

Like, I’ve got quite a few Qubes machines lying around, many of them in different locations, and would love to have a play around with sys-headscale, but I’m struggling to see where the “killer function” is over other methods of networking Qubes machines.

So tell me :grinning:

I saw it, but I was hoping to get a bit more detail.

Well, maybe this could be the project that changes this. What do you think?