Comment by deskamess | Hacker News Reader

Comment by deskamess | Hacker News Reader

In the Enterprise version it would be nice to see:

- Named groups/subnets for a single NetMakerServer (lets say [Users] and [Servers])

- Access control capability: Allow/disallow inter/intra group connectivity. For example, using the previous groups : [Users] can connect to [Servers] only (not other [Users]) and [Servers] can connect to other [servers] only (not [Users]). Basically, for this case, the peer list returned to NetClient's only contain the [Servers]. More generally, it is the concept of public vs private - not sure if this is needed on a group/subnet or individual netclient level.

- MFA requirement for certain Groups. Example: [Users] who have not connected to the network in the last X hours/other criteria will need to MFA (provided by NetMaker+TOTP or other IDP like Okta). Server-server connections will never need to MFA. This is one of those Enterprise security check list items in security reviews.

- Ideally: Ability to run the NetMakerServer on Windows (IIS, Nginx, Apache) without having to launch containers/install VM's.

Congratulation ons on your launch. Will keep an eye on things.

I think you'll be happy with the Enterprise version based on your list, we've had very similar thoughts. One question on the final point, where do you see the need to install the server on Windows? We've had one other user ask for this, but not sure if I see the need.

Company uses Windows exclusively and there are no in-house Linux ops/admin skills. We have good ops/admins resources for Windows and we need to leverage that. A native solution (even if running behind Apache/Nginx) is preferable. In addition this would be a critical part of the infrastructure so we would want that piece to be somewhat familiar to the ops/admin resources for debugging (access the box, restart a service, troubleshoot networking issues, etc).

Edit: This is a requirement for self-hosted but if your enterprise solutions offers it as a highly available service that would by-pass this issue. It would need to be HA and spread in such a way that a single cloud provider going down does not affect things.

I think until we get more users requesting this, it will probably stick on the back burner for some time. We've designed several server components assuming it's deployed on Linux, and it's streamlined for containers. However, if there's an org interested in pursing this (and has some golang + ops skills) it should be do-able with a bit of effort, and we can provide some advice. It might make for a good community project.

> One question on the final point, where do you see the need to install the server on Windows?

Can any client be an egress node?

Currently just Linux machines can be egress nodes.

What is an 'egress node'?

An exit node; if node a is an exit node, node b can route its traffic through a - which among other things can allow access to resources whitelisted to node a's public ip from b.

Reply on news.ycombinator.com