Imagine also a scenario that there is a Snikket server behind the NAT, and port 55820 is one of the UDP ports that is forwarded to Snikket. For you the world turns around NS8, but not for everyone else.
Thanks a lot! This is the answer. Use the command redis-cli etc. to change the port, because it cannot be done from the GUI. Command line tools/instructions are perfectly fine for me.
I have not tested those instructions yet, but I trust that they should work. Maybe I have missed them because the port 55820 is still used in those examples.
All the rest of moralization answers are utterly useless. I donât need anyone to teach me morals, and I donât have time to read these messages or to engage with them.
Actually I see the need of changing the listening port only if you are planning to add worker nodes to NS8 and they will be deployed both in your LAN and outside of it.
In this mixed scenario worker nodes receive the same VPN endpoint, for example ns8.domain.com:55821. If the LAN DNS resolves that host name to an internal IP, changing the listening port is mandatory. But if the NAT device can apply the port-forwarding rule also from internal connections (hairpin NAT) the listening port change should not be needed, again.
Yes, NS8 is still in development - and the developers are doing a really good job in my opinion - and so it is natural that certain things donât work yet or certain options change or disappear during development.
But: âdashohoxhaâ didnât expect a special solution. He simply tried to use a function offered in the GUI - it didnât work and âdashohoxhaâ reported it here.
Thatâs exactly what testing software is all about, right? As âtestersâ of these early versions, we are required to test the software and report errors or strange behavior. Correct?
Therefore, I donât understand why âdashohoxhaâ should first explain why he even wants to use a function that doesnât work or whether there couldnât be another way? This would only be useful if the strategic question was whether this function should be offered or removed. But this was âonlyâ about reporting a function that was offered.
If manual port adjustment is no longer provided (for certain reasons) - or is no longer provided for in the GUI - then please remove it from the GUI or at least comment on it in the GUI?
Not doing this saves the developers some time - but at the same time it takes away the testersâ time to report other errors - or even the desire to do so.
I myself try to contribute to NS8 by testing it as extensively as possible and then reporting any âerrorsâ. At the same time, I donât want to bother the forum or developers with reports that are based on operating errors. For example, before I report a bug or ask for help with a function, I always look for information in the forum and the instructions. But with NS8 I often donât find anything about it in the forum (yet) and not in the instructions - or it doesnât exist more current.
Personally, I miss a starting point or a list of (current) âsourcesâ where ânormal usersâ (NS8 is not primarily aimed at developers) can first obtain information (e.g. about known or reported errors or strategy changes) before possibly .posts unnecessarily in the forum and in turn keeps others busy.
My experience is that many misunderstandings are based on the use of non-native language.
Of course, the forum cannot yet provide all information about NS8. However, without a point of contact, it is difficult for testers to find out which errors or peculiarities have already been reported. Git is great for collaborative work, but confusing for inexperienced helpers - and not everyone should post an error message there.
It would therefore be interesting, for example, to have a subsection in the forum in which you can report or comment on errors in a more targeted manner. And maybe another category too. e.g. to find information about new ways of dealing with NS8 (GUI and console) or to exchange ideas about them. For example, I have tons of questions about NS8 that get lost relatively quickly in the forum. I recently started an entry with a collection of errors*, but apparently no one can find it - at least there has been no response so far.
Even after todayâs core update there are problems (ipv4 address suddenly unconfigured), but where is the best place to store this?
FYI, you can quite easily tunnel wireguard in wireguard. Itâs an EXTREMELY efficient VPN. so stand up your wireguard environment first, set the config as anything except wg0 since Neth wants wg0.
if you are running just a single node, edit the firewall and close the port. or just do a local forward.
all this has likely been posted, this is a rather long read, and I didnât.
