I can see Fedora 34… it works for a year… and Debian 11 this one is great. I’m liking it very much, despite the users are really ugly people (ejejejeje)
¿What about Rocky and Alma Linux?
Read up-topic a bit–they aren’t supported, at least not with the 8.x releases.
1 Like
Hi there!! I’m installing the NS8, just for fun, in a Debian 11, after follow the instructions I put this line.
“source /etc/profile.d/nethserver.sh && create-cluster debian11.miserver.local:55820 10.5.4.0/24 Nethesis,1234”
Then access via web as the developer says in instructions… and is not working.
Any ideas??
@giacomo IMVHO it’s… interesting that you made the same path of mantainers of IpFire. For their platform they jumped from CentOS to Debian 
1 Like
FWIW:
Given the NSA and CISA’s recent publication on technical guidance on properly securing VPN servers.
Would it be possible to utilize strongswan with strongMan or another IKE/IPSEC VPN solution out of the box vs. wireguard?
Hi David,
In the NS8 prototype the Wireguard VPN is an internal component used to secure communications among the cluster nodes. It is not a VPN service used by people.
No, as Wireguard is implemented as a Linux module it works without user-space daemons and is really simple to configure for the cluster purposes.
Thanks, I misunderstood the purpose for wireguard being listed in the OS requirements documentation.
wait, does NS 8 come with support for clustering?
No generic support to “clustering”. Instead it looks like a cluster/group of nodes that can be managed from a single admin interface.
4 Likes
This means that NS8 = Wireguard welded into the installation (with no way to disable it)?
I am aware of the (in my ignorant opinion seriously wrong) decision to implement wireguard as part of the Linux Kernel but… i mean… With this decision sysadmin cannot avoid the use of wireguard, if NS8 is the choice.
And by my point of view that’s… “not ideal”. Really not. Straight and simple: IPSec is already part of IPv6. Which is the need for a newer not-yet-fully-debugged VPN toolset?
Quite a decades ago, some people without a lot of computational power and memory but the brain at work, designed something “simple enough” for being reliable and powerful enough to solve problems, not creating that. This lead to SCSI, TCIP/IP (yes, quite bugged until supernetting, but no one seen internet exploding, at that time. Moreover… they also were from northern america, sometimes people with that flag don’t see the world, only their yard).
Transform a “one man band” server into “a multiplied cluster gang setup” makes me rises concerns about the overhead (in my perception, climbing to the Monte Bianco) of the arrangement. Due, the greed of computational power.
I am also aware of the great upgrade in terms of scalability (tomorrow the containers could be deployed into new-parents server with more beer underlying), redundancy (a cluster is quite tougher to destroy than bare metal) or migration (new server, meet your boss, the Cluster Orchestrator, it will transform you into a fully configured truck without stopping the old smoking lorry).
Question is: the “S” of “Small” is going to fall soon from “Small Medium Enterprises”?
I can also understand that the higher core availability of CPUs (boosted by “hyper threading” that all x64 CPU makers allow) can be used better with so parcelled activity and with a lot of processes but…
May I remind you the “apocalypse class bug” and the subsequent child, nephews and way huge descendants generated? You remember the “007Bug” Spectre and his odd-brother Meltdown?
I know, currently no working exploit published. I know, currently no proof of concept catch in the wild.
But some years ago, an exploit put into an hard drive firmware a small kernel, with few megabytes of cache used partly for ram. And now, before the silicon shortage, an NVMe controller in a 8tb drive had 2gb of cache… I installed a virtual server few days ago with that amount of ram. Yes, i should make customer spend more money on hardware.
The fear i have for any kind of Spectre-descendants is that the gate for branch prediction and CPU cache is open, and could take… quite a lot of years to re-write the way the CPUs and SoCs are designed. So if maybe buying a “3 years old” technology could not have the same vulnerabilites of a lot of hardware out there and mitigation should avoid. But mitigations come at price of cutting capabilites, and newer hardware comes not so cheap, even without the help of Redmond inc (which will boost soon the sales of not-available CPUs) or of the silicon shortage.
The only green side is that saves quite a bunch of power… that’s for sure a silver lining.
Ok… this post is gone way out of track, topic, common sense. Or not, I hope.
Maybe I’m only lost into a land of dark mirrors, but from here, there’s quite a… sense of something bad that’s going to happen.
Hi Michael
I wasn’t a fan of Wireguard - and still am not. But it does have it’s uses…
For starters, IPsec is by now over 20 years old. Sure it’s been tested and analysed very well, but it still has (major) caveats.
In a major country like Germany, with T-Online as the major provider (ex monopolist), it’s almost not possible to use IPsec on a private internet connection. T-Online almost completly precludes “bridging”, the vdsl has to come in over a pre-specified vLan (Which not all boxes can handle).
Almost everyone uses OpenVPN in Germany for this reason. IPsec does not run over a (forwardable) port, like OpenVPN does (Normally UDP 1194), which makes IPsec hardly usable.
In politically restrictive countries like Russia and China, OpenVPN can use TCP 443, making it possible to pass thru the Great Firewall in China, which IPsec can’t. There’s also possible deniability issues with IPsec.
OpenVPN is by now also almost 20 years old, if I’m correct, it appeared around 2001. Also very well code-vetted, it has become the defacto standard for most VPNs out there.
Both IPsec and OpenVPN have a similiar sized (large) codebase, making checking for bugs and vetting the software much harder.
Fast forward to 2019, where Wireguard come on the scene. It’s easily twice as fast as IPsec and OpenVPN. The codebase is about 4500 lines, at least 20 times smaller than OpenVPN, making a good vetting simple.
It’s very ideal for IOT or server server connections, even inside the same hardware / cluster. Eg for connecting secured Docker environments.
The GUIs aren’t as polished as eg Viscosity for OpenVPN. There are security caveats, like the connecter IP cached / saved on the server side (making deniability impossible). It can’t use TCP, making it a non candidate for passing thru the chinese Firewall.
On the plus side, the code’s simplicity makes for great strides also with the GUIs.
Also connecting / reconnecting is extremly fast, easily 10x faster than an already fast OpenVPN!
And the changing of Networks (client / server sides) are with Wireguard almost a non-issue. Both IPsec and OpenVPN don’t handle this very well, and are fairly slow in reconnecting.
There are valid reasons for all three VPNs. One just needs to know the advantages and disadvantages of each VPN, and compare this with the intended usage.
Sometimes, someone has to play the part of Advocatus Diabolis…
(The devils lawyer, arguing for both sides!).
My 2 cents
Andy
Why are you acting like you didn’t already know this? Because you’ve commented on it previously, in this very topic. Like this one, almost four months ago, in response to @mark_nl’s mention of WireGuard:
Or this, a few days later:
This isn’t news.
That does not make it better by my point of view, @danb35. If the (in my opinion) “wrong” is already been told and repeated, that does not make it feared/doubted/worrying less.
Explaining and delivering reasons why in my opinion is not good maybe can help other people to think. But anyway seems wireguard is the beloved creature for a lot of humans. And falling in love cannot be avoided, only remember how hurts (as Toxin Twins sang, is so hard on the knees).
A lot of people says “newer is not better”. I don’t agree with that, but I find suspiciously fast a project that landed into linux kernel in a bit more than 60 months.
Maybe the code is so “damn good”, I don’t have enough coding skill to disagree with that, but it feels like a fast mole that made the nest into the garden. A good one? I think it’s necessary to take a bit more time to answer.
…
Check out the history, the Wireguard code exists since 2016 and was implemented in various systems.
AFAIU Wireguard is just used for internal container communication, you can still have OpenVPN or IPSEC.
If you want to have a look at wireguard, you may test the module on a VM…
Absolutely true, and for the NS8 core (and just for that) the choice was Wireguard (as you said: widespread and reviewed as Linux is, out-of-the-box, lightweight, fast, simple, …).
Yes, they cannot avoid it. By now, we consider “no core VPN at all” as unsupported scenario. However it is theoretically possible to run without the core VPN, provided that the existing infrastructure has a secure internal and private network.
This is why some devs here in Nethesis are not trying to build NS8 on Kubernetes: too heavy, even its so-called “lightweight” variants! K8s has been our first experiment: I think we learnt a lot from it.
NS8-scratchpad is the 2nd attempt, a compromise. It still aims to be attractive for the SME world while providing a modern platform to run applications, as integrated as NethServer has been since the beginning.
So the answer is: “No, it isn’t going to fall, absolutely”
5 Likes
what is real, and does it have dokuwiki inside the dashboard?!
1 Like
ns8 development obviously
2 Likes
Where is the coffee and the pizza? I think it’s the main thing for developers work… 
6 Likes