afeiszli

Blog post for context: https://www.netmaker.io/resources/netmaker-goes-open-source-...

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.

Netmaker also has a relay setup, when you don't want to do P2P: https://www.netmaker.io/features/relay

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.

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.

You might find the github or docs more helpful, which are more geared to a technical audience: - https://github.com/gravitl/netmaker - https://docs.netmaker.io/

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.

Really cool!

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!

Yeah that’s what we used, but not all Linux supports it, and that still leaves non-Linux as well. But hosts files are universal.

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.

You can do a WireGuard server on Kubernetes with Netmaker:

- https://itnext.io/multi-cluster-kubernetes-networking-with-n...

- https://itnext.io/multi-cluster-kubernetes-networking-with-n...

You can run WireGuard in a docker client without giving it access to your internal networks.

Hey! Netmaker author here. I think it’d be a cool option for this use case. We have some users already doing blockchain stuff. Benefits are it’s self hosted, so you don’t need to depend on a SaaS, no mandatory 3rd party auth, and a lot faster because of kernel WireGuard.

We don't have our own mobile client yet, so right now we rely on the WireGuard app. You configure a gateway, and then generate raw WireGuard configs + QR codes which hook them into the network: https://docs.netmaker.org/external-clients.html

I'd like to offer Netmaker as an alternative. Caveat, I'm one of the creators so grain of salt, etc.

It's completely self-hosted, so none of your traffic will go through our servers. You can also use basic auth by default (though there is also OAuth). Finally, as a bonus, it's much faster because you can use kernel WireGuard.

I won't claim it's as user-friendly as Tailscale (yet). It definitely requires more technical knowledge to set up, especially considering it's not a SaaS. But if you're willing to get through the initial setup (Day 0 / Day 1), you should be golden.

Check out Netmaker if you're looking for something WireGuard based. We had a post about it a couple weeks ago:

https://news.ycombinator.com/item?id=29809830

Netmaker repo owner here. Let us know if you have any questions and we can help out!

Currently auth is limited to OAuth integration with Google, Azure, and GitHub, but we'll be building this out in the coming months.

Routers are hard because they all have their custom OS's, and we need to do system level stuff besides just WireGuard. We're open to expanding the range where needed, and will happily support anyone in the community who wants to port the client to a new OS, but for now we're sticking to OpenWRT and FreeBSD as the supported routers.

Currently just Linux machines can be egress nodes.