The VPN endpoint parameter is usually set to the leader FQDN, UDP port 55820. Changing it from the default is rarely needed.
However it often happens that the leader FQDN set with the cluster initialization is changed from the Nodes page (set-fqdn). This procedure does not update the VPN endpoint value, that is left with a stale (and invalid) value.
[ ] Remove the Advanced section in cluster initialization page
[ ] Remove the VPN endpoint form in the leader promotion dialog
[ ] Fix the leader node details page to show VPN endpoint and real VPN port
[ ] Update the relevant doc sections
[ ] Document how to set a custom VPN endpoint with the command line, for corner cases
Alternative solutions
The VPN endpoint parameter must be set also in the Nodes > Set FQDN form
As a working FQDN DNS record is a requirement for NS8 installation, it is easier to rely on it for the VPN endpoint, and use the CLI for exceptional use cases.
Additional context
This is a typical scenario.
In cluster initialization an invalid FQDN is set, and it is used by default as VPN endpoint:
After a while I realize the cluster FQDN is invalid. The Nodes > Set FQDN can fix it, but after the form is saved VPN endpoint is still invalid:
Screenshot of leader node details, showing that the VPN card is missing some details: VPN endpoint and actual Wireguard listening port number (is it hardcoded?). WG listening port can differ from the VPN endpoint port if a port-forwarding appliance is deployed.
The VPN endpoint parameter is usually set to the leader FQDN, UDP port 55820. Changing it from the default is rarely needed.
However it often happens that the leader FQDN set with the cluster initialization is changed from the Nodes page (set-fqdn). This procedure does not update the VPN endpoint value, that is left with a stale (and invalid) value.
Proposed solution
This enhancement proposal aims to:
Alternative solutions
The VPN endpoint parameter must be set also in the Nodes > Set FQDN form
As a working FQDN DNS record is a requirement for NS8 installation, it is easier to rely on it for the VPN endpoint, and use the CLI for exceptional use cases.
Additional context
This is a typical scenario.
In cluster initialization an invalid FQDN is set, and it is used by default as VPN endpoint:
After a while I realize the cluster FQDN is invalid. The Nodes > Set FQDN can fix it, but after the form is saved
VPN endpoint
is still invalid:If I add a worker node I hit bugs like https://github.com/NethServer/dev/issues/6958
Screenshot of leader node details, showing that the VPN card is missing some details: VPN endpoint and actual Wireguard listening port number (is it hardcoded?). WG listening port can differ from the VPN endpoint port if a port-forwarding appliance is deployed.
See also