afeiszli

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.

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.

Thanks for the feedback. Just wondering, with 0.0.0.0, are you accessing using "external clients" or the regular netclient?

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.