I want to use a port different from 55820 for the VPN, because this port is being used for something else. The admin interface allows me to change it, but finally I find out that it is not actually changed.
I am not sure, is this a bug or a feature?
It would be nice to clarify this issue before the stable release.
WireGuard port 55820
The UDP port used by WireGuard in the creation of the cluster VPN is now fixed to 55820. Clusters already created with a custom port number must be fixed manually before updating the core to Beta 2. For example if the custom port is 55821 run on the leader node the following steps to fix it…
Only if exposed to the Internet, which would not be needed…
VPNs exist for a long time now, no one forces you to use your beloved WireGuard. You can use IPsec or OpenVPN between sites, and pipe the Cluster VPN through closed enviironments.
WireGuard hardcodes the endpoint IP into the VPN-config, so man in the middle or direct attacks are bound to fail…
On the other hand, any server available on the Internet will already use well known ports, like Mail, Web etc. These are also generally easier to attack, as they are per se available to everyone.
Any reason for this “feature”? I can’t see any.
In my case, this UDP port is being used for something else, so I have to change it.
Being familiar with WireGuard, I can change it manually on the config files. But on the admin interface it is still displayed as 55820, which does not look promising.
On NS8, still in RC status, you installed a “mission critical” app? And it’s not another instance of WG using that port? Since it’s something so secret…
Your problem for not understanding a Beta or RC candidate status! And not reading the requirements…Tough!
The port is a requirement, not a feature. If you want you can break your NS8 anytime you want to, nobody is going to care in future!
NS8 is in Pre-Release testing mode.
Almost everyone here is waiting for release!
On a BETA or Pre-Release System it’s never a good idea to install something off the scope of the Beta - no one has time for this!
Second: To be honest, I plainly think you installed a hand set Wireguard for a client (Or maybe this is in a cloud without you providing ANY information!) and are not telling us the full situation!
What are the chances of an important app which “must” use a “standard” default WireGuard Port? -
I’d say less than 1 in 65500 !!!
You here for the first time, and are misusing the beta phase without giving any Feedback, important for this phase.
No serious admin will install any productive app on a beta or prelease. There can still be modifications (Like this one) which would make the install unusable…
Now, who is being disrespectful?
No feedback on why you’re using port 55820
You are not reading the critical infos, yet asking questions about these very facts about upgrading / updating!
This question has been decided by the Devs here, no discussion worth entering into…
And WHO says your App is more important than critical inside stuff used by NS8?
Andy’s harshness aside, he’s correct–move whatever’s using 55820/UDP to another port, or to another server entirely. NS8, like NS7, is not intended to run on top of a server that’s already doing other things; it’s designed to take over the whole server. I don’t know why the devs took away the possibility of changing that port, though I’d strongly suspect there was a strong reason for doing so at this point if it had been there previously–hopefully they’ll chime in here.
But you really shouldn’t plan on running other services on your NS8 box that NS8 itself isn’t aware of.
…and why can’t that “critical inside stuff” (that isn’t critical at all if there’s only one node in the cluster) listen on a different port? It could in B1 and B2. I suspect there’s a reason, but it’s not an unreasonable question.
And I also see NO reason to use a “well known” port for an “internal” service, not planned for use outside of NS8 “nodes”.
I can imagine hardcoding the port has advantages (not probing what port is actually used in updates) for Devs, but there’s no other plausible reason noted…
My “harshness” stems from the fact that for a first time poster, our user is being outright impolite by not posting ANY relevant information - and obviously hasn’t had the current, latest Read The Fine Manual about the current state of the Beta / RC1…
See the subject titled “WireGuard port 55820”…
And being evasive on the probable use by a hand made Wireguard VPN, as I do not believe he randomly choose that port!
As well known here, I respect all knowledge levels, any nationalities, on a professional level.
No political or religion discussions!!!
This is a forum about Open Source Software, and I intend to keep my input to that, at the level others have come to expect from me.
The lowest I’ll publicly stoop to in “political” discussions here is about RH / IBM - and maybe Oracle, as these are significantly relevant for OpenSource.
This isn’t about or even similiar to earlier “Distro Wars”, but an inherent thing in most cultures I’m aware of: If you give your Word, you stick by it. It’s a matter of honor - and by major extension also Trust!
In what way is 55820/udp a “well-known” port? That’s a serious question; Google doesn’t show any standard use, much less assignment, for that port.
So what if he is? Why does it matter what he’s running there? And why would you assume it’s WG? AFAICT, 55820 isn’t a default or recommend port for Wireguard (the closest I’m seeing, though I’m not all that familiar with WG, is 51820).
Yes, it’s in the release notes, and it’s clearly a deliberate change, so there’s almost certainly a reason behind it–I don’t know what that reason is, and hopefully someone can chime in with that information. But be that as it may, the only current answer for OP is to either reconfigure whatever’s on 55820 to listen somewhere else, or to run it on a different system.
That’s what I mean.
The only “known” application using that port seems to be WireGuard!
(Typical variations of the standard, like 2222 / 2223 for SSH, etc).
I know that “well known ports” refer to ports below 1024, and are root accessible, but in context of this post…
This usage is not helping in any way debugging NS8 before Release…
For an “exotic” use-case of a beta / rc candidate server, I’m not the one to suggest against any “best practices” here!
I do really think hard coding the Cluster VPN to another port can easily break the system when updating, and without any further infos, I’m not keen on helping here…
That is correct.
So the service should be correctly designed for not allowing buffer overflow, RCE, XSS and so on.
However, a known and so critical port for the cluster could be a target for remote attacks (if exposed on internet) or from a malware or DDOS. It’s harder to exploit all of this due to Wireguard used for running for the traffic (which greately reduce chances of breaking the protocol and sniff or malform the traffic).
I mean… goals for NS8 are for hybrid local/cloud infrastructure… innit?
The server manager port of NethGUI could not be changed (980). In cockpit-based server manager, this option had been available.
I hope that (sooner than later) this kind of option (change the cluster communication default port) could be achieved.
I know, it’s not that easy!
If changed the traffic should be available during migration on both ports, every cluster node should be alerted of the port change, reload management with new port, then at the end the cluster overlord should wait until the last node has switched to custom port to kill and delete the default/older port. It’s a process, not a simple port/configuration change. And could take… days?
Design, realize and debug a reliable yet agile procedure is quite a complex task, because could sever the connection between master and the nodes.
This probably lead to a “later” label on this option.
@Andy_Wismer I’m quite the PITA master, in these days, try to not steal that crown from me
Imagine a scenario with two NS8 clusters behind a NAT: port 55820 can be forwarded to just one instance, the other one needs a custom port. On the NAT device the port-forwarding rules should be something like:
PUBLIC_IP:55820 → NS8_ONE:55820
PUBLIC_IP:55821 → NS8_TWO:55820
In this scenario when you create NS8_TWO cluster, under the Advanced section of the Create cluster procedure, customize the public endpoint of the VPN (hostname:port).
The same attributes can be changed when a node is promoted to leader: the other nodes need to know how to reach its Wireguard port even if there is a NAT device in the middle.
So from the UI there is no way to change the Wireguard listening port number.
However, if another process is listening on port 55820 and Wireguard conflicts with it, you can still change Wireguard configuration and pick another listening port number manually. In the release notes of Beta 2 there are some useful commands to fix the VPN address:port in Redis and configure Firewalld and Wireguard accordingly: Release notes — NS8 documentation. It is wise to do it before joining other nodes!
Welcome aboard on our community @dashohoxha
as I can see, this is your first post and I think that your tone does not align with our values.
I try to suggest how you should have written the sentence
“I have to change it” → Is there any other option? How can I change it?
“Any reason for this “feature”? I can’t see any.” → I don’t understand NethServer Team choice, could you explain why? Probably there is a good reason for that.
Please be aware that we’re on RC, as Andy suggested, don’t put NS where you can’t change things a lot of things are changed and are going to change
You can find your answer above.
For everyone turn down the temperature… @davidep answer should clarify any doubts