Feature Request: support for custom devices/operating systems

[nazarewk]

Is your feature request related to a problem? Please describe.

This is a feature request for running a full NetBird client on not explicitly supported operating systems (Mikrotik's RouterOS).

The original issue #496 veered off-topic from supporting limited-capability devices towards the possibility of running NetBird on custom devices or operating systems, which by no means addresses the original purpose of running on low-powered/hardware spec devices in a limited capacity to reduce resource consumption.

Additional context
see #496 for prior discussion.

#496 (comment)
The latest relevant post from @excavador outlines 3 implementation options for RouterOS:
A) embedding RouterOS configuration library within NetBird
B) providing config for and calling out to external programs to set up the operating system where needed (firewall, wireguard etc.)
C) implement a (most likely Go) plugin system for achieving the same as option B

Hello!

Thank you so much for your reply!

I take a look to netbird source code, and it's clear how you build up abstraction on WireGuard/DNS/Firewall configuration
I have understanding how to implement MikroTik API client to perform the same actions on Mikrotik side
Pre-requisite - should be container on MikriTik in host network mode (to share NAT traversal port directly)

So, @mlsmaycon , my questiion the following:
Option A. would you like to have support of RouterOS API directly in netbird client source code? (my be with some golang build tag)
OR
Option B. would you like to have some "external" kind of configuration, where netbird receive in configuration path to custom scripts?
OR
OptionC. would you like to have some "plugin" kind of configuration, where netbird load golang plugin of certain interface?

The difference the followings
Option A. Simpler for user, for it will force to add all other devices, different from RouterOS, directly to the source code base
Option B. Ideal for non-developers, system administrators. They will able to DIY integration with own router or very custom devices
Option C. Ideal for developer, implement own plugin, load it, no injection to codebase

@mlsmaycon I could implement any approach, my question to you - what NetBird team prefer?

[excavador]

@nazarewk Hello!

Could you please clarify about any next steps?

Like NetBird team will discuss internally, or something else? I do not mind put my power to implementation, what I mind - make it "for nothing", i.e. if imlementation will not even accepted by the NetBird.

That's why I am asking clarification of the issue and my question is "how to move forward?" from current situtation

[nazarewk]

Generally, running a full NetBird client on a custom device won't help in terms of supporting low-spec devices, which most of the networking devices are. I am not trying to discourage you, but I am still not 100% sure this will solve your problem, as NetBird client can easily use upwards of 50 MB of RAM.

To give you an update: we do have some brief-but-ongoing discussions in our internal Slack. I am veering towards option B due to both involving the least maintenance and being the most attractive to sysops/IT departments who aren't the most proficient with coding. Part of the team likes the benefits outlined, but we haven't reached a consensus yet.

PS: The topic looks a lot like an extended variant of #3591 , which is another benefit and maybe could be tackled together.

[excavador]

Generally, running a full NetBird client on a custom device won't help in terms of supporting low-spec devices, which most of the networking devices are. I am not trying to discourage you, but I am still not 100% sure this will solve your problem, as NetBird client can easily use upwards of 50 MB of RAM.

This feature makes sense only for huge throughout of Wireguard (in case of my Mikrotik - it able to tackle 1Gbps, but due to container overhead take only 200-300 Mbps) and it means device will have 50 Mb of RAM

To give you an update: we do have some brief-but-ongoing discussions in our internal Slack. I am veering towards option B due to both involving the least maintenance and being the most attractive to sysops/IT departments who aren't the most proficient with coding. Part of the team likes the benefits outlined, but we haven't reached a consensus yet.

Clear

PS: The topic looks a lot like an extended variant of #3591 , which is another benefit and maybe could be tackled together.

Yes, agree

[excavador]

@nazarewk more considerations to your team

In case of "small hardware" this feature does not make any sense (and any solution okay), because the most likely people will put NetBird only for management commands
It does not matter, do you have 500 Kbps or 10 Kbps for shell.

This feature itself about optimization of huge traffic, like side-to-side VPC connections (my case - hyrbid between self-hosted and Scaleway)
In case when you have 200Mbps or 1Gbps traffic - it makes sense and important - you have huge device, you except huge traffic.
Only in this case (huge device+huge traffic) the difference between "use wireguard from container" or "use wireguard from device" is significant and you definitely will have enough RAM to make netbird client up-and-running

@nazarewk even if device NOT able to manage netbird - does not matter!
In this case I could put netbird to some host INSIDE network, and it will be device configuration problem and script problem on how to forward netbird requests to device.

The only single problem with "external" orchestration is dealing with port for NAT traversal - but long story short this is not a problem

My 2 cents