I don't want to be a hater, but exposing access to your homelab through a "fully vibe coded" application (it's mentioned at the bottom of the README) is probably not a good idea.
I guess at least they're being honest, but I would agree - there's a large delta between Al-assistance and Al-driven, and "vibe coding" is one step further (just accepting everything Al does without critique, so long as it "works").
Great for prototyping, really bad for exposing anything of any value to the internet.
Github should have "LLM" as language for repos that self report to be vibe coded or at least this kind of disclosure should be at the top of the readme not after thought.
Also the "If you're Anti-AI please don't use this." is pretty funny :D
I guess I must be "Anti-AI" when I think this kind of code is wild to rely on.
I fully support the AI self-disclosure, but what I wonder what it is about AI generated code that makes this a separate problem from any other code where you don't know the programmer's competence?
Is it because the AI can generate code that looks like it was made by a competent programmer, and is therefore deceiving you?
But whatever the reason, I think that if we use it as a way to shame the people who do tell us then we can be assured that willingness to disclose it going forward will be pretty abysmal.
I think it makes sense for stuff that is fully AI generated to the point where you commit the prompts to git. At that point, they become the real "source code" and the generated code is more of a build artifact. It makes sense to tag the language as "LLM" instead of e.g. "Python" because that's what contributors will be expected to touch when interacting with the codebase.
there is a non-zero chance that the human programmer has an interest in producing correct, secure code. there is zero chance than an LLM has the same interest. maybe those two are closer together in some cases, but not in many others.
LLMs and Humans fundamentally write different kind of code.
As humans we segment functionality and by nature avoid extra work as much as possible. Meaning reading someone else's code even if they are less competent makes sense and you can see the intention.
With LLM code everything is mixed together with no rime or reason and unless separately specified old useless functionality won't be cleaned out just because it is no longer used.
Also just the fact that people who use LLMs to vibe code bigger things usually aren't capable of reviewing what is going on in the first place, but if you are dangerous enough yourself to write a bigger piece of software you probably do know something about the problem on a deeper level and can test it.
I don't really see shaming. If you vibe code something and you are proud of it good for you, but LLMs currently are not capable of creating good software.
I must be Doing It Wrong(TM), because my experience has been pretty negative overall. Is there like a FAQ or a HOWTO or hell even a MAKE.MONEY.FAST floating around that might clue me in?
I guess I have to implement the habit of checking such things, since I never assume such a possibility. I prefer this info to be at the top of the readme, though – much more information value than the logo that deceived me into thinking this is a mature project.
Regardless; what benefits this would have over Wireguard?
Perhaps not requiring a wireguard client installed on the machine you are accessing from. There are several circumstances where installing a VPN client isn't possible or practical
It’s getting scary how many security related apps are being vibe coded by people with very little security experience (not a knock heh on op, they could very well be experienced).
I'm pro security. The gall to put something out there, pretend it being vibe coded is not a big deal and possibly exposing hundreds of people to security issues. Jesus.
I mean you are free to not use it, it's for personal use. I was annoyed by all the vpn based solutions and built knocker to have something that works without installing it on each and every device.
It's open source. Audit it like you would any other service that exposed your homelab to the Internet. How do you know XYZ repo isn't coded for some bootcampers capstone project? I bet those are even less secure.
Edit: should have mentioned I am a bootcamp grad, not just throwing random shade.
If I had to audit security services for exposing homelab to the internet, I wouldn't use those services in the first place. I'm fine trying things out, but this is a very important security boundary, and it's a solved problem. Why risk it with an auditor who does it for a hobby (me)?
I mean it's just using firewalld.
You can't inspect the rules.
For me it's simple enough that it shouldn't be a big security issue, but I understand and that's why I wrote that in the readme.
I will never, ever understand this "single-packet authentication" "port knocking" fetish. It has never made sense. Bin it, along with fail2ban, and just set up WireGuard.
Your network authentication should not be a fun game or series of Rube Goldberg contraptions.
I’m not super familiar with the intricacies of fail2ban and don’t currently understand why op made that claim but would very much like to know more because he is talking about a topic he is highly regarded for and I respect that. I just don’t have the context.
Port-knocking mainly mitigates slow distributed-brute-force login attacks, and works best when ports are interleaved with several tripwire black-hole and knock-port-close firewall rules.
Use-cases:
1. helps auto-ban hosts doing port-scans or using online vulnerability scanners
2. helps reduce further ingress for a few minutes as the hostile sees the site is "down". Generally, try to waste as much of a problem users time as possible, as it changes the economics of breaking networked systems.
3. the firewall rule-trigger delay means hostiles have a harder time guessing which action triggered a IP ban. If every login attempt costs 3 days, folks would have to be pretty committed to breaking into a simple website.
4. keeps failed login log noise to a minimum, so spotting actual problems is easier
5. Easier to forensically analyze the remote packet stream when doing a packet dump tap, as only the key user traffic is present
6. buys time to patch vulnerable code when zero day exploits hits other hosts exposed services
7. most administrative ssh password-less key traffic should be tunneled over SSL web services, and thus attackers have a greater challenge figuring out if dynamic service-switching is even active
People that say it isn't a "security policy" are somewhat correct, but are also naive when it comes to the reality of dealing with nuisance web traffic.
Fail2ban is slightly different in that it is for setting up tripwires for failed email logins, and known web-vulnerability scanners etc. Then whispering that IP ban period to the firewall (must override the default config.)
Finally, if the IP address for some application login session changes more than 5 times an hour, one should also whisper a ban to the firewalls. These IP ban rules are often automatically shared between groups to reduce forum spam, VoIP attacks, and problem users. Popular cloud-based VPN/proxies/Tor-exit-nodes run out of unique IPs faster than most assume.
I recently wrote a deception / honeypot service that does some similar stuff so that all makes sense to me and I think the general strategy of impose costs on attackers by making them expose more of their infrastructure etc are actually a really good move especially in the context of developing an early warning signal.
I had some additional logic that gave me a really easy but unintuitive way to tell with an incredibly high degree of confidence the difference between a bot and a human on keyboard scenario and for what it’s worth I think that is the specific thing that makes it worth the effort.
If I have reasons to suspect it’s a bot I just drop the request and move on with my day. The signal to noise ratio isn’t worth it to me.
Depends on the use-case, IPsec is often not supported by many LANs. Also, network crossing is 1 badly configured client away from full infrastructure worming.
At some point, the idealism of white-listed pears and VPN will fail due to maintenance service costs. Two things may be true at the same time friend. =3
"We had a secure VPN option set up, but then we had to replace our Ivanti VPN solution so we switched to Fortigate. Then there were some concerns so we jumped to Sonicwall. After that debacle we finally got the budget to go with Cisco and I'm sure everything will be fine now!"
They can't get in but they can still fill my logs up, so fail2ban cuts them off after a few failures.
Also by collecting data on the IP addresses that are triggering fail2ban I can identify networks and/or ASes that disproportionally host malicious traffic and block them at a global level.
Why bother logging them at all? What is this doing for you? You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to.
> Why bother logging them at all? What is this doing for you?
Logging both successful and failed requests is important for troubleshooting my systems, especially the client-facing ones (a subset of which are the only ones that are accessible to the open internet), and failed authentication attempts are just one sort of request failure. Sometimes those failures are legitimate client systems where someone misconfigured something, and the logs allow me to troubleshoot that after the fact. That it can also be fed to fail2ban to block attackers is just another benefit.
> You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to.
Obviously in a world full of botted computers, IoT devices, etc. it's true that an attacker can hypothetically come from anywhere, but in practice at least from the perspective of a small service provider I just don't see that happen. I'm aware that you are involved with much larger scale operations than I'm likely to ever touch so perhaps that's where our experiences differ. No one's targeting my services specifically, they're just scanning the internet for whatever's out there and occasionally happen to stumble upon one of my systems that needs to be accessible to wherever my clients happen to bring their devices.
Sure, I see random domestic residential ISP addresses get banned from individual servers from time to time, but I never see the organized attacks I see which are usually coming from small hosting providers half way around the world from my clients. I have on multiple occasions seen fail2ban fire off rapidly sequential IP addresses like xxx.xxx.xxx.1 followed by xxx.xxx.xxx.2 then xxx.xxx.xxx.3, or in other cases a series of semi-random addresses all in the same subnet, which then triggers my network block and magically they're stopped instead of just moving on to another network. If I were to be packet sniffing on the outside of the relevant firewall I'm sure I'd see another address in the blocked network trying to do its thing but I've never looked.
> You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to
I'm not totally following what Fail2Ban has to do with Wireguard. Are we talking strictly about homelabs you don't expose to the internet?
Because I have a homelab I can connect to with Wireguard. That's great. But there are certain services I want to expose to everybody. So I have a VPS that can connect to my homelab via Wireguard and forward certain domain traffic to it.
That's a safe setup in that I don't expose my IP to the internet and don't have to open ports, but I could still be DDOS'd. Would it not make sense for me to use Fail2Ban (or some kind of rate limiting) even if I'm using Wireguard? I can still be DDOS'd.
IMHO Fial2ban, just like port knocking, isn't cargo cult security. They are a single tool that can be included in a general system security arsenal, not the only tool you should use but one of a suite of tools that can be used depending on what you want to achieve.
Personally I use fwknop for port knocking as it doesn't suffer from replay attacks as it's an encrypted packet. But still serves the same niche
The point being made is that unless "what you want to achieve" is "run a tool that isn't improving your security posture", port knocking isn't providing value to the security model.
I can't agree that it's "a tool that isn't improving your security posture", if it's a layer on top of other tools, you might argue it's effectiveness isn't great but to say it's effectively nothing is a reach.
Knocking can cut down on grinding. I have in the past created setups where you had to knock prior to establishing a VPN connection, and given the semi-regular problems with VPN implementations I really don't feel bad about that. Fortigate, Sonicwall, Cisco, Ivanti, etc - sure a big part of it is "don't run VPNs based on big legacy codebases" but who's to say there won't be implementation problems found (or introduced given "Jia Tan" style attacks) in Wireguard?
Is knocking incredibly weak security through obscurity? Sure, but part of what it does is cut down on log volume.
Sure there is, if the attacker has to fulfil some basic obfuscation then it cuts down on the amount of crypto work you have to do before ignoring the packet.
It's not extra security but it is a little extra efficiency.
Wireguard has something like this built in though, the PresharedKey (which is in addition to the public key crypto, and doesn't reduce your security to the level of a shared-key system). It's still more work to verify that than a port knock however.
This has no value at all. WireGuard assumes an adversary trying to make it do extra work doing handshakes; a big chunk of the WireGuard paper discusses it. I don't think this is as important a problem as Jason does (but it's his baby), but either way: part of the point of WireGuard is that it's safe to hang out on the open Internet this way.
Every door you close, is one less someone can break.
Every complex services running, is a door someone can potentially break. Even with the most secure and battle tested service, you never know where someone fucked up and introduced an exploit or backdoor. Happened too often to be not a concern. XZ Utils backdoor for example was just last year.
> Your network authentication should not be a fun game or series of Rube Goldberg contraptions.
Just to be super clear.. using this in place of something like WireGuard is absolutely not an improvement. It’s actively worse in the majority of scenarios assuming you can manage to secure your keys.
I somehow doubt that it is quite truly worse in every single scenario, and that there is not one single scenario that port knocking may be better utilized than WireGuard.
I also find it hard to believe it is engineering malpractice to use one technology over another.
What happens if there is a vulnerability in WireGuard? Or if WireGuard traffic is not allowed in or out of a network due to a policy or security restriction?
Yes, of course, should this just be an optional gadget for a setup, which is already as safe as possible for the situation. After all, when the port has been opened, your setup is also open for attacks. The knockers purpose is to reduce the timeframe of when your system is accessible for attackers.
I mostly agree.. there’s a couple of very specific scenarios where maybe something like knockd makes sense I think but they are all scenarios where you’re doing things covertly, not as a general authentication mechanism.
As a side note I just happen to be reading a book at the moment that contains a fairly detailed walkthrough of the procedure required to access the Russian SVRs headquarters in New York in 1995.
Think of this as an analogue version and in no way a perfect analogy but it does include a step that has more or less the same security properties as this… anyways here’s a relevant quote:
“After an SVR officer passed through various checkpoints in the mission’s lower floors, he would take an elevator or stairs to an eighth-floor lobby that had two steel doors. Neither had any identifying signs.
One was used by the SVR, the other by the GRU. The SVR’s door had a brass plate and knob, but there was no keyhole. To open the door, the head of the screw in the lower right corner of the brass plate had to be touched with a metal object, such as a wedding ring or a coin.
The metal would connect the screw to the brass plate, completing an electrical circuit that would snap open the door’s bolt lock and sometimes shock the person holding the coin.The door opened into a small cloakroom. No jackets or suit coats were allowed inside the rezidentura because they could be used to conceal documents and hide miniature cameras.
SVR officers left their coats, cell phones, portable computers, and all other electronic devices in lockers. A camera videotaped everyone who entered the cloakroom. It was added after several officers discovered someone had stolen money from wallets left in jackets. Another solid steel door with a numeric lock that required a four-digit code to open led from the cloakroom into the rezidentura.
A male secretary sat near the door and kept track of who entered, exited, and at what times. A hallway to the left led to the main corridor, which was ninety feet long and had offices along either side. ”
Excerpt from
Comrade J by Pete Earley
As another funny side note… I once discovered years ago that the North Koreans had a facility like this that they used to run a bunch of financing intelligence operations using drugs in Singapore where I was at the time and thought it would be funny to go and visit. It was in a business complex rather than a dedicated diplomatic facility from memory. But as I recall it was a similar scenario of unmarked door with no keyhole.
WireGuard is designed to be silent preceding a cryptographically authenticated INIT message. It's a superset of whatever security features you'd get from "knocking".
In fairness, most of the fervor for these kind of knock-based flows predate Wireguard existing. They come from the era where OpenVPN and friends were the common practice in that space, and I would not have considered "add OpenVPN" to be a rational way to improve the security of anything I was doing.
Eh. I've used OpenVPN over many years for many kinds of problems. I'm hesitant to call it perfectly reasonable even for the most mundane use case of "running an entirely vanilla virtual private network". For the use case of securely wrapping services in the way Wireguard can do, it's hilariously bad.
OpenVPN is basically 1000 configuration options and magic incantations wearing a trenchcoat, and if you get any of them wrong the whole thing crumbles (or worse, appears to work but is not secure).
It's part of a long line of cargo culted security things people do because it makes them feel on-the-ball; they're all anti-tiger rocks. Even before WireGuard, port knocking never made sense, and for most of its history it was actively harmful.
I use tailscale for this.
But I can't have two vps running at the same time on android, nor do I want to install tailscale on every device I own.
I created knocker exactly for this reason.
It is a VPN. The point was to block all external traffic except for VPN traffic. Then make sure your VPN is secure, and you're all set. When you want to connect to some service, connect to the VPN first and then connect to the service through the VPN. Then all your traffic has actual security and not just some light obfuscation via secret handshake.
IMO, "only wireguard" is too restrictive of a policy - I also trust openssh and nginx to be open to the internet, if configured moderately carefully. Most FOSS servers that are widely deployed on the internet are safe to be deployed on the internet, or we'd know about it. I reviewed something that's not widely deployed on the internet though (Apache Zookeeper) and couldn't convince myself that every code path was properly checking authentication. That would have to go behind a VPN.
Nowadays public facing client IPs are often shared by thousands of users behind CGNAT. IP based firewall rules are useful when the peers have their own static IP address, but provide no real security when the IP address is shared.
This is vibe coded security through obscurity, i. e. quite useless. Use Tailscale or a self hosted VPN.
The way I see it, port knocking may not be a valid security measure but it can be a good filter. It will allow you to filter out port scanning and other mass cracking attempts.
My opinion is that being able to filter out noise and false positives from authentication logs allows you to improve your actual security measures.
An other advantage is that it may hide information about your system making it harder for an attacker to target you based on a broad scan without doing some (usually detectable) targeted reconnaissance first. For example imagine someone found a 0-day in one of the services behind the port-knock and is scanning for the vulnerable version.
It does however add another cog in the machine that may break.
I implemented something similar as a caddy module, then I realized that if I was connected to a public wifi network I was actually authorizing the whole bunch of people that were connected to it with me. How do you avoid this, or is it just not important?
It shouldn't be your only layer of security, and then it's not important. Think of it as replacing explicit IP black/whitelisting - you still want a login wall or something, but now you restrict access to guess logins or otherwise obtain access through app vulnerabilities etc.
It's a compromise.It's not as secure as using a VPN, but it's way more convenient, since only one device has to have a knocker client on it without needing any sort of VPN.
The likelihood of someone is on the same network as you noticing your servic, try to hack it, before the TTL expires again is IMO quite low.
This is without taking into account that the services themselves have their own security and login processes, getting a port open doesn't mean the service is hacked.
Port knocking is a very hacky technique that was used:
1- In the 90s were security was whatever
2- In modern days as a way to keep your logs squeaky clean ( although you get 99% there with custom ports)
3- As a cute warm up exercise that you code yourself with what's available in your system. (iptables? a couple of python scripts communicating with each other?)
It's not a security mechanism, and downloading external dependencies or code (especially if vibecoded) is a net loss (by a huge margin).
It's also a waste of time to overengineer for the reasons noted above, I've seen supposedly encrypted port knocking implementations. It feels as if someone had a security checklist and then a checklist for that checklist.
There's nothing "hacky" about port knocking. It was never meant to be a complete security solution—nothing is.
But it works very well as an additional layer of security. Sec nerds often scoff at "security through obscurity", but it is a very valid strategy. Running sshd on a random high port is not inherently more secure, but it avoids the vast majority of dumb scanners that spam port 22, which is why all my systems do that. Camouflage is underrated, yet wildly effective. You can see how well it works in nature.
In any case, this is not a port knocking solution anyway, as I mentioned in another comment.
> This is ideal for homelab environments where you want to expose services to the internet without a persistent VPN connection, while minimizing your public-facing attack surface.
To an untrained eye, the wording here could be construed to imply that this is more secure than a VPN. Might be worth a reword to clarify why one might prefer it want to over a VPN.
Sorry if i wasn't clear.
It isn't more secure, it's just more convenient because it works in every network, without needing to set up a VPN connection on each device.
I created this because I always have a VPN on my devices, and I can't have tailscale running with that, in addition to tailscale killing my battery life on android.
Neat project, thanks for sharing. I'll stay away since it was vibecoded, but I appreciate the honesty.
Though this is not technically a "knocker", but a typical token-based auth gateway. I experimented with something similar recently as well, and think it has its use cases.
But I would agree with some of the comments here. If you need to expose many services to the internet, especially if their protocols are not encrypted, then a tunneling/mesh/overlay network would be a better solution. I was a happy tinc user for several years, and WireGuard now fills that purpose well. As much as people use solutions like Tailscale, ZeroTier, etc., I personally don't trust them, and would prefer to roll my own with WG. It's not that difficult anyway.
There's also Teleport, which is more of an identity-aware proxy, and it worked well last time I tried it, but I wouldn't use it for personal use.
Hey I'm the creator of knocker!
I actually wanted to write a blog post about it before posting, but OP already did that.
If you have any questions just let me know!
Will go into more details why I created in the blog post coming very soon! Just doing the final touches right now.
The "port knocking" has surfaced often since the early 2000s, but it continues to be a rather silly exercise in making security-by-obscurity look more complicated while not really helping all that much.
Briefly looking at the diagram at the top of the repo, it looks like you "knock" with an API key. Why not just run a reverse proxy in front of (whatever service you're trying to protect) and use the API keys there? To harden further, do some sort of real authentication (PKI, client certs). If you want your logs to look cleaner, install and actually configure fail2ban.
If you need to manage risk for a legacy service that has a requirement to be internet exposed, I suggest checking out https://knocknoc.io/ for a self-hosted and/or cloud based solution that was not built with vibe coding, but actual customer security use cases.
They provide 2FA and/or single sign-on to allow just in time access to internet
exposed applications which remain hidden from unauthenticated/approved users.
The authentication part does not look much different from password authentication (key ≈ password), and the "Configurable TTL" bit is somewhat confusing, the first part of the sentence assigns the TTL to API keys but the second part says it applies to IPs being whitelisted. I would expect that TTL for a key means that after the TTL expires the key itself becomes unusable.
> IP based exclusion should not be considered a security measure
Apologies in advance if I'm missing something obvious here, but are you saying an IP allow list is not a standard security practice? If so I'd appreciate further explanation.
It's useful when the client always has its own static IP that _doesn't change_ between sessions. In this case, where the public facing IP may be shared by thousands of users, it provides no real security. All you'd have to do to gain access would be getting the client IP and finding some way of getting on the same network. Which in many cases could be as easy as subscribing to the same cell network or other ISP, or connecting to the guest wifi network of an office building.
Thanks for filling in the details. I agree that an IP allow list works best for users who are alone on an IP that doesn't change often, which is the case for a majority of home internet users but not when they're away from home.
Unfortunately there's an increasing number of home internet connections behind CGNat, as IPv4 adresses run out (and IPv6 doesn't gain momentum, heaven knows why)
I guess it's partially because ISPs are perfectly happy selling crippled internet connectivity as the base service and charging hefty premiums for "luxuries" like static IPs. It has also become common to only offer static IPs to business customers.
IPv4 addresses have run out, everything has been allocated, and they are now being traded.
IPv6 is slowly growing in popularity. Google stats are close to 50%. If your ISP has IPv6, you might be accessing Hacker News with IPv6 since they added support recently.
I use fwknop in a similar manner, the main advantage it has is it's using an encrypted UDP packet. It's ability to call shell scripts for more advanced uses is its best feature. I have a packet set up for a rolling restart of all my services as well as ssh access
I use this thing called sshd that listens on only a single port and its main advantage is that it uses actual cryptography to authenticate using a client keypair.
Fwknop uses HMAC keys so quite good crypto by itself, but it's for single shot commands. Good for keeping the ssh port locked until you actually need it. I use it on top of SSH key pairs as part of my layered security, Just as any good access control strategy should.
I had hoped this would allow me to use various patterns of knocking on my desk to perform system actions. Do the cut-and-a-hair-shave knock to log in, or taptaptaptap-wait-tap to lock the screen, etc. Maybe with two microphones you could even distinguish between left and right handed knocks.
Sorry, but I felt a bit of nostalgia here; I wrote some port knocking code a couple decades ago, this is straight-up "neat" and I'm surprised it is still around.
If you're running a homelab, the likelihood that you're interested in removing cloud-dependencies from your stack is above average. If that's the case, Tailscale is out.
Tailscale is just an added unnecessary external dependency layer (& security attack surface) on top of vanilla Wireguard. And in 2025 it's easier to run vanilla Wireguard than it's ever been.
Normally I'd agree with the philosophy, but I don't really see how you can say this about vanilla Wireguard in particular considering how involved it is, especially if you have more than 2 devices that you want to connect together.
Not only do you need to manually manage the keys for each device and make sure they're present in every other device's configuration, but plain Wireguard also cannot punch through NATs and firewalls without any open ports like Tailscale can, as far as I know.
Combine that with the fact that networking issues can be some of the hardest to diagnose and fix, and something like Tailscale becomes a no-brainer. If you prefer using plain Wireguard instead, that's fine, and I still use it too for some more specific use cases, but trying to argue that Tailscale is entirely unnecessary is just wrong.
> but plain Wireguard also cannot punch through NATs and firewalls without any open ports like Tailscale can, as far as I know
I could be wrong, but I think Tailscale just does what you can do on Wireguard, which is `PersistentKeepAlive`. It lets a wireguard client periodically ping another to keep the NAT mapping open.
What that does is allow existing outgoing connections through a NAT to remain open long-term, it doesn't actually help with establishing an initial connection if both sides are behind a NAT or closed firewall.
Tailscale handles this, and can establish a direct connection between two machines without either of them needing an open port listening for new connections.
> trying to argue that Tailscale is entirely unnecessary is just wrong
Tailscale is great if it meets your requirements, & it probably does for most - I wasn't arguing that at all. Only that it won't be an option for everyone: in particular a non-tiny subset of home server hosters.
It exists on a spectrum. Time for hobbies including homelabbing is limited, so while someone who's retired and has all the time in the world to tinker can go self host every last single thing, I'd bet that more people just want to be able to have something that works without a huge depency on the cloud. As long as the bits are on the hard drive in my basement, how the packets get routed around is less critical, to some people, I imagine.
Everybody's got their own set of beliefs and understandings, and they get to decide how they want their homelab to work.
For me, tailscale fits in just right. Others can come to their own conclusion based on how they feel about networking and points of failure and depency and all that.
I haven't tried Headscale but isn't it more complicated than Wireguard?
The selling point of Tailscale is that they simplify Wireguard UX by adding a proprietary control server - this adds complexity to the stack (extra component) but simplifies user experience (Tailscale run the control server for you).
Headscale seems like it's complicating the stack (adding an extra component) as well as complicating the user experience (you have to maintain two components yourself now instead of just the one Wireguard instance).
Granted I presume the Headscale control server might simplify management of your Wireguard instance but... you're still maintaining the control server yourself.
It likely does add some complexity, though it’s relative. Self-hosting is always going to have some overhead. Managing WireGuard servers and clients and associated keys etc is probably the part that is most annoying, so I can see how it might be easier to throw that over the fence to Headscale even though it is introducing another dependency.
I was speaking more to doing it all in-house, versus outsourcing things to Tailscale, a third party not fully under one’s control, even if they act of behalf of the user. I think I largely agree with what you said.
Fwiw I bought an Asus router that came with Wireguard pre-installed & has a nice management UI. It handles client onboarding via a simple QR code that integrates with the Wireguard mobile app - even my mother had no issue setting it up.
Buying hardware is an investment (& not something everyone can do) but I've really never understood the point of the control server from the perspective of an open-source self-hoster (for a business like Tailscale it makes sense as it introduces an element of control, user dependency & likely analytics of some value).
There's still a lot that can be done to improve Wireguard's UX but I think the Asus example proves it can be done well. Headscale seems to be doing the worst of both worlds (promoting an architecture & user-flow of a proprietary closed-source competitor, while still requiring CLI setup & instance maintenance). For example, it seems to me like it would be better for them to wrap Wireguard directly & integrate with the actual Wireguard mobile app instead of having people install proprietary Tailscale app on their phones to use your own open-source self-hosted control server.
It's much simpler to babysit a service than to manage a relatively higher risk thing like generating, rotating and communicating public keys between all of the nodes in the network.
The idea itself sounds fun though