It's definitely lacking on the unit-testing side and we should do more there, but we think integration tests are the more important of the two in this scenario, because the most fragile bits are the interactions between client-client and client-server. It's a lot harder to self-contain those tests without deploying the platform and clients on various infrastructures.
Worth noting, the WireGuard creator has specifically mentioned these sort of management features (user auth, automated configuration and coordination, ACL's) as out-of-scope of the WireGuard project. He wanted to keep it as simple as possible, and left it to 3rd parties to develop VPN platforms using WireGuard.
You can lock it down a good amount:
- 80 is only required for Caddy to request certificates. If you BYO certs, you can take that off
- TURN is optional, so if you disable TURN then dont need 3479 or 8089
- The remaining ports are only for specific features (EMQX and Prometheus exporter) which are not enabled by default.
So really, you could get it down to just 443. However, this should be better documented.
Also worth noting these are all server-side requirements. The actual WireGuard clients do not need these ports open.
We do have a CLA, and put it in place for this very reason. It is more complex legally, but I meant more in terms of the community. Better to make people happy by going less restrictive over time then to start out with Apache and switch to something more restrictive and upset a bunch of people.
I think it's worth doing your own investigation on how often traffic is getting relayed via Tailscale. We don't have numbers on it, but have had users who experienced very high latency with Tailscale, and after doing some traffic analysis, discovered it was getting relayed halfway across the country. Tailscale does a fantastic job at NAT traversal, but it's still a worthwhile consideration.
SSPL is a bit more restrictive, but politics also have a lot to do with it. "Open Source" is just a term, technically anyone could call their license open source, but most people only consider a license open source if the OSI (a foundation) specifically approves it. Mongo tried and failed to get SSPL approved by OSI: https://blog.tidelift.com/what-i-learned-from-the-server-sid...
Kilo is cool! And works. It will be similar, just sort of depends on what you're comfortable with and what sort of management features you need. Some people like a UI where they can see all their nodes and troubleshoot without having to SSH, which is a primary advantage, but Kilo is probably better for smaller setups that are purely for Kubernetes.
Netmaker guy here, and I'll be the first to tell you that if you have a static setup of, let's say 5 machines or less, then there's no need for something as complex as Netmaker. It's really useful for people who have many machines, or machines that will move around dynamically. Or, if you need to route traffic through a NAT gateway. A static setup is fine for technical people and small networks, it's just not scalable. As an analogy, you wouldn't run Kubernetes if you just need to deploy 3 docker containers, but as the complexity grows, you need a management system.
NAS should work if it's linux or freebsd based. For mobile you (currently) have to use our "client gateway", which accesses the network just using a regular WireGuard config file, which you can scan from the Netmaker UI using the WireGuard app on your phone. But it works well. However, we've got a mobile app in the works.
Netmaker may help with this. You configure an "Egress Gateway" to 0.0.0.0/0 as your internet VPN, inside of a Netmaker network of 10.10.0.0/24. We do our routing rules differently and it is meant to be compatible. However, I'm a bit surprised you have this issue with regular WireGuard, as it tends to be quite stable for this sort of setup in my experience.
Hi, worth noting another point on this. Netmaker has "Client Gateways", which allow you to generate and modify raw WireGuard config files. This is extremely useful for integrating custom WireGuard setups. For instance, generate a config file, modify it, put it on a router, and boom, site-to-site. https://www.netmaker.io/features/ingress
Hi! Netmaker here. At the time of this writing this is true, but we're making some licensing changes this sprint, which I think will make people very happy. We started with SSPL just because it's much easier to go from more restrictive to less restrictive, as opposed to the alternative.
However, several months ago we moved all of the client-side code to Apache-2.0, and are about to make the server-side code FOSS-compatible.
We decided to use Lago with our SaaS. Billing is super complicated and Lago handles everything we need out of the box. Building this stuff would have been a nightmare. Really cool!
Split DNS is super complicated to implement client side. We halfway implemented a solution and backtracked, eventually settling on just setting /etc/hosts. There's way too many variables involved across all the different operating systems.