How this plumbing is expected to be implemented? For example Cloudflare Warp uses Wireguard for its VPN solution, but all key exchanges and other stuff happens via HTTPS REST calls. Is it expected for any non-trivial implementation to build a different "control" protocol? For me it sounds like a dangerous approach. While wireguard protocol will be safe and audited, those additional proprietary protocols will hinder cross-platform usage (for example you had to use reverse-engineered Cloudflare Warp implementation for Linux until recently and I guess that BSDs will use it forever) and might expose security vulnerabilities on their own.
Yes, you are exactly right. Wireguard is a typical example of a thing I'd call myopic-cryptographer-protocol. Solve one problem in the minimal fashion that can be called proof-of-concept, do it in a maybe-more-secure way and call it done. Everything else, like proper key distribution and user management, which you need for a real-world deployment that isn't just a personal toy, is left as an exercise to the reader. All the readers will screw up in different ways, after which the myopic cryptographer will explain that his protocol was of course perfect and there is nothing wrong with it, you are just holding it wrong...
Another might be that existing VPN solutions will gut the bottom of their stack and use WireGuard for that, thereby reducing complexity and increasing performance.
I think this was the point of WG. OpenVPN/IPSec/etc are beasts since they include all of the above. OpenVPN is TLS based! That makes adding it into the kernel difficult, and you need kernel access or exotic stuff like VPP/DPDK for speed.
I do agree with your overall sentiment, though. The next step is to make a higher level protocol on top.
Nobody really needs enterprise VPN crap, that stuff does far too much weird stuff that is totally unrelated to what a VPN should do, like patch management, malware scanning, firewalling, and other useless box-ticking.
What we do need is a proper replacement for roughly the things OpenVPN plus PAM can do. A VPN plus some user and key management.
It is a completely reasonable requirement of a large organization to ensure an endpoint meets certain criteria before being allowed access to an internal network.
I'm not arguing that Wireguard has an obligation to tackle that problem themselves. I'm arguing against your assertion that VPN access should be completely decoupled from ensuring endpoint security.
Lets be honest, any malicious endpoint can easily bypass those 'endpoint security' checks.
All they're good for is checking that unpatched (but not yet exploited/evil) endpoints can't connect to the network, which is of marginal benefit compared to allowing them to connect but requiring they patch before accessing risky resources (like the internet or email).
Not all compromised machines are the same. Is the user of the machine an insider threat or not? Does the login user have admin rights to the machine or not? And what you said in the last sentence is exactly how some VPN solutions can be configured: Limited access to network resources for updates and management, and only when fully matching version/anti-malware/etc. requirements can you connect to all resources.
Anyway. Like I said, I think Wireguard is amazing - I used PiVPN (which can be installed on any .deb distro) to set up a simple gateway for my laptop and phone to be always connected for DNS and local-network access. I'm very grateful for its architecture and simplicity in that regard.
I think there's an external issue here though. There might be regulation or some sort of liability concern regarding known unpatched clients connecting to the network. In that context simple checks make a lot of sense.
