NoMachine Support

Your questions answered

Knowledge Base

Searching in: Articles & FAQs
Filter the search results
Applies to:
Last update:
Searching in: Articles & FAQs
ID: AR05R01088
Applies to: NoMachine Server
Added on: 2020-05-18
Last update: 2020-11-13
How to choose the most appropriate Cloud Server setup and configure it to allow access to NoMachine Servers (v. 6)

This guide is for system administrators who need to provide users access to computers or desktops in the corporate network and through a single point of access. The single point of access will be via Cloud Server. The users’ desktops/servers/workstations will be referred to as child servers. The child servers in these guidelines will be Enterprise Desktops.


Table of Contents
1. Preliminary operations for all supported operating systems
1.1. Default TCP PORTS used by NoMachine

2. Most common use-cases
2.1. Use Case 1: LAN or VPN
2.2. Use Case 2: Cloud Server behind a NAT
2.3. Use Case 3: Cloud Server in a DMZ
3. How to setup a NoMachine Cloud Server multi-server environment
3.1. Add the child servers to the Cloud Server
3.2. Deeper insight: traffic forwarding and user authentication
3.3. Dispatch the connection to a specific child server (optional)
3.4. Limit access to one or more servers (optional)
3.5. Limit access to a group of servers (optional)
3.6. Set-up the HA failover cluster (optional)
4. Supported Authentication Methods and known limitations
5. Our main test environments
6. FAQs

 

1. Preliminary operations for all supported operating systems

1) Setup and configure the authentication subsystem by referring to the documentation of your Operating System.

TIP
 

The user must have a valid account with the same username on MachineA and on MachineB. 



This account can be a local system account, or a LDAP or an AD account.


2) Install NoMachine Cloud Server, CS1 on MachineA.

TIP
 

Notes for LDAP and AD Domain

The Cloud Server and the Enterprise Desktop must be in the same AD domain or  connected to the same LDAP directory.


Preferably, install the Cloud Server on an AD client and not on the Domain Controller.

If this is strictly necessary, please read here:  https://www.nomachine.com/AR04O00925.


3) Install a NoMachine server (e.g. the Enterprise Desktop, ED1) on MachineB.

Ensure that the Cloud Server can contact the child server on MachineB, for example by using the Ping utility (ping hostname) if ‘ping’ has not been disabled. 
Communication between Cloud Server and child server uses by default the TCP port 4000. Check if that port is accessible, for example by connecting via NoMachine client.


4) Ensure that the clients can connect to the Cloud Server and that the Cloud Server can connect to the Enterprise Desktop. You can check that for example by starting a NoMachine session from the Cloud Server to Enterprise Desktop, or by using the ‘ping’ utility or by connecting to another service running on that host. The necessary TCP ports for NoMachine data traffic must be open in the firewall.

 

1.1. Default TCP PORTS used by NoMachine


4000 for connections by NX protocol
22 for connections by SSH protocol on Linux and macOS
4022 for connections by SSH protocol on Windows
4080 and 4443 for web connections by HTTP and HTTPS



For a complete list of TCP and local ports required by NoMachine, read here: https://www.nomachine.com/AR01L00770
 

TIP
 

External IP and Port Forwarding
When the clients need to connect to the Cloud Server over the Internet:

The Cloud Server host needs a public IP (static) with the necessary open port to allow acces OR port forwarding configured on router. In this case, the client will connect to the IP of the router. See Use Case 2 in this guide.

2. Most common use-cases

2.1. Use Case 1: LAN or VPN

What: To provide employees in a corporate network a single point of access to their workstations.


When: NoMachine clients, Cloud Server and Enterprise Desktops are all on the same network (LAN or VPN).


How: If the NoMachine clients can connect to the Enterprise Desktop, the Cloud Server can use the ‘system’ forward method to establish a direct client-Enterprise Desktop connection.

 

 

2.2. Use Case 2: Cloud Server behind a NAT

What: To provide employees external access to the corporate network through a single point of access to their workstations.


When: NoMachine clients connect over the internet to the Cloud Server and cannot connect directly to the Enterprise Desktop (they are not in the same LAN or VPN). The Cloud Server is behind a NAT router or firewall.


How:  The client traffic will be relayed by the Cloud Server to the Enterprise Desktop by means of the ‘tunnel’ forward method.

 

2.3. Use Case 3: Cloud Server in a DMZ

What: To provide employees external access to the corporate network through a single point of access to their workstations.

When: NoMachine clients connect over the internet to the Cloud Server and cannot connect directly to the Enterprise Desktop (they are not in the same LAN or VPN). The Cloud Server is in a DMZ

How:  The client traffic will be relayed by the Cloud Server to the Enterprise Desktop by means of the ‘tunnel’ forward method.

 

3. How to setup a NoMachine Cloud Server multi-server environment

3.1. Add the child servers to the Cloud Server

Naming convention:

NoMachine Cloud Server, CS1 is installed on MachineA
NoMachine Enterprise Desktop, ED1 is installed on MachineB.

Step 1 - Add the child server to the Cloud Server

You can do that via graphical interface, https://www.nomachine.com/adding-servers-to-nomachine-cloud-server-via-the-user-interface.

Otherwise, it's possible to do that via command line on a console. Administrative privileges are requested.

On MachineA, where CS1 is installed execute the following.

Linux and macOS
Execute from a terminal:
$ sudo /etc/NX/nxserver --serveradd IP_of_ED1 --label "Enterprise Desktop ED1"

Verify that the child server has been correctly added:
$ sudo /etc/NX/nxserver --serverlist

IMPORTANT: If the Cloud Server is installed in a DMZ, client connections can be forwarded to the Enterprise Desktop only via the ‘tunnel’ method. Set it as default method, since the other forward methods cannot be used in this case and are therefore redundant:

 

$ sudo /etc/NX/nxserver --serveredit IP_of_ED1   --forward-nx-methods tunnel

$ sudo /etc/NX/nxserver --serveredit  IP_of_ED1  --forward-ssh-methods tunnel

Use --protocol and --port to specify with which protocol (NX or SSH) should be the connection tunnelled to the Enterprise Desktop and on which port. By default its’ NX protocol on port 4000.

 

Windows
Open a CMD console as administrator. 
This can be a local account with administrative privileges or a domain administrator if MachineA and MachineB are both part of the same AD domain.

Remember that if the ED1 host is Linux or macOS, it’s necessary to manually add the AD domain andministrators to the ‘sudoers’ group.

In the CMD console, move to the 'bin' directory under the NoMachine installation and add the Enterprise Desktop:
> cd C:\Program files (x86)\NoMachine\bin\

> nxserver --serveradd IP_of_ED1 --label "Enterprise Desktop ED1”

Verify that the child server has been correctly added:

> nxserver --serverlist

If the Cloud Server is installed in a DMZ, client connections can be forwarded to the Enterprise Desktop only via the ‘tunnel’ method. Set it as default method since the other forward methods cannot be used in this case and are therefore redundant:

> nxserver --serveredit IP_of_ED1   --protocol PROTOCOL --port PORT 
--forward-nx-methods tunnel

> nxserver --serveredit  IP_of_ED1  --protocol PROTOCOL --port PORT --forward-ssh-methods tunnel

Use --protocol and --port to specify with which protocol (NX or SSH) should be the connection tunnelled to the Enterprise Desktop and on which port. By default its’ NX protocol on port 4000.


While adding the child server, you will be prompted to log-in on the child server ED1 with your account in order to add the public part of the RSA key pair used by the Cloud Server to authenticate on the child server. 
This key pair is made of:
installation directory/etc/keys/node.localhost.id_rsa
installation directory/etc/keys/node.localhost.id_rsa.pub

 

3.2. Deeper insight: traffic forwarding and user authentication

How the client traffic is forwarded to the child server and how users authenticate to the child server
.

i) Token - The client will authenticate to the child server with OTP, a One Time Password token which uniquely identifies the client. The connection will be forwarded after the user has been authorized on the Cloud Server (CS1).



When: this method works when the client can connect to the Enterprise Desktop directly. It's the default method when user connects by NX protocol. It can be set also for the SSH protocol but it requires a manual configuration, see the Cloud Server administration’s guide https://www.nomachine.com/DT02O00123

Supported authentications methods:
client connections by NX protocol: password; private key...
client connections by SSH protocol: password; private key...
client connections by web: password; private key...

ii) System - The client will authenticate on the child server by using the same credentials already used for authenticating on the Cloud Server host. The connection will be forwarded after the user has been authorised on the Cloud Server. 



When: this method works when the client can reach the Enterprise Desktop directly. It's the default method when user connects by SSH protocol. It can be set also for client connections by NX protocol. If the user’s account has the same password on MachineA (CS1) and MachineB (ED1), the same credentials will be re-used automatically to log-in to the Enterprise Desktop. If you want a second authentication, set a different password.

Supported authentications methods:
client connections by NX protocol: password; private key...
client connections by SSH protocol: password; private key...
client connections by web: password; private key...

iii) Tunnel - The client traffic is relayed through the Cloud Server with the protocol specified for the server-to-server communication. 


When: this method is the fallback for token and system methods when the client cannot reach the Enterprise Desktop. The user doesn’t need to authorise on the Enterprise Desktop since the tunnel connection is already established. 
This is the only way for users to authenticate when the Cloud Server is in DMZ and the child servers are on their own separate corporate LAN or VPN.

Supported authentications methods:
client connections by NX protocol: password; private key...
client connections by SSH protocol: password; private key...
client connections by web: password; private key...
 

3.3. Dispatch the connection to a specific child server (optional)

What: dispatch the user's connection to a specific Enterprise Desktop.


When:  users don't need to access more than one Enterprise Desktop
.

How: assign a specific Enterprise Desktop to the user or to a NoMachine group of users.
 

Linux and macOS
Execute the following commands from a terminal.

Assign the given user to the given child serverb>

$ sudo /etc/NX/nxserver --useredit USERNAME --forward-connection SERVER:PORT

where SERVER:PORT is the name of the child server, as it appears in the output of 'nxserver --serverlist --extended'.

Assign a NoMachine group of users to the given child server

Create a NoMachine group of users and assign users to this group:

$ sudo /etc/NX/nxserver --groupadd GROUPNAME

$ sudo /etc/NX/nxserver --useredit USERNAME --group GROUPNAME

and assign a child server to that group:

$ sudo /etc/NX/nxserver --groupedit GROUPNAME --forward-connection SERVER:PORT

 

Windows
Open a CMD console as administrator and execute the following commands. 


Assign the given user to the given child server

> cd C:\Program files (x86)\NoMachine\bin\

> nxserver --useredit USERNAME --forward-connection SERVER:PORT

where SERVER:PORT is the name of the child server, as it appears in the output of 'nxserver --serverlist --extended'.

Assign a NoMachine group of users to the given child server

Create a NoMachine group of users and assign users to this group:

> nxserver --groupadd GROUPNAME

> nxserver --useredit USERNAME --group GROUPNAME

and assign a child server to that group:

> nxserver --groupedit GROUPNAME --forward-connection SERVER:PORT

 

3.4. Limit access access to one or more servers (optional)

What: allow or forbid user(s) to some Enterprise Desktops


When: users need to access more than one Enterprise Desktop but not all of them (by default all users can access all Enterprise Desktops).


How: create the appropriate profile rule on the Cloud Server. The rule can be applied on a per-user basis and on a per-group basis and has to be set for a specific Enterprise Desktop.

It's possible to create NoMachine groups of users, completely separated from system groups of users. On Linux and macOS, as an alternative, it's possible to use already existent system groups. Support for Windows system groups is coming soon.

Linux and macOS
Execute the following commands from a terminal.
Forbid the given user to access a specific child server
$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVER:PORT --value no --user USERNAME

Forbid all users except one to access a specific child server

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVER:PORT --value no

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVER:PORT --value yes --user USERNAME

Forbid a group of users to access a specific child server. Use a system group

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVER:PORT --value no --group SYSTEMGROUPNAME

Forbid all users except those belonging to a specific system group to access a specific child server

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVER:PORT --value no

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVER:PORT --value yes --group SYSTEMGROUPNAME

To use NoMachine groups, create a NoMachine group of users and assign users to this group:

$ sudo /etc/NX/nxserver --groupadd GROUPNAME

$ sudo /etc/NX/nxserver --useredit USERNAME --group GROUPNAME

Then apply any of the rules above to the NoMachine group.

If you want to allow/deny a user only when connecting from a certain IP or range of IPs, you can use the same format of rules above, and specify also the IP(s). For example:


$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVER:PORT --value no --user USERNAME --address XX.XX.XX.*

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVER:PORT --value no --group SYSTEMGROUPNAME --address XX.XX.XX.*

where SERVER:PORT is the name of the child server, as it appears in the output of 'nxserver --serverlist --extended'.

 

Windows
Open a CMD console as administrator and execute the following commands.

Forbid the given user to access a specific child server

> cd C:\Program files (x86)\NoMachine\bin\

>  nxserver --ruleadd --class server --type SERVER:PORT --value no --user USERNAME

Forbid all users except one to access a specific child server

>  nxserver --ruleadd --class server --type SERVER:PORT --value no

>  nxserver --ruleadd --class server --type SERVER:PORT --value yes --user USERNAME

Forbid a group of users to access a specific child server.

Firstly, create a NoMachine group of users and assign users to this group:

>  nxserver --groupadd GROUPNAME

>  nxserver --useredit USERNAME --group GROUPNAME

Then apply the rules to the group: >  nxserver --ruleadd --class server --type SERVER:PORT --value no

>  nxserver --ruleadd --class server --type SERVER:PORT --value yes --group SYSTEMGROUPNAME

If you want to allow/deny a user only when when connecting from a certain IP or range of IPs, you can use the same format of rules above, and specify also the IP(s). For example:

>  nxserver --ruleadd --class server --type SERVER:PORT --value no --user USERNAME --address XX.XX.XX.*

>  nxserver --ruleadd --class server --type SERVER:PORT --value no --group SYSTEMGROUPNAME --address XX.XX.XX.*

where SERVER:PORT is the name of the child server, as it appears in the output of 'nxserver --serverlist --extended'.

 

3.5. Limit access to a group of servers (optional)

What: allow or forbid users to a group of Enterprise Desktops


When: a group of Enterprise Desktops has to be made visible only to a group of users


How: create the group of servers and set the appropriate profile rule on the Cloud Server. The rule can be applied on a per-group of users basis or to single users.

It's possible to create NoMachine groups of users, completely separated from system groups of users. On Linux and macOS, as an alternative, it's possible to use already existent system groups. Support for Windows system groups is coming soon.

Linux and macOS
Execute the following commands from a terminal.
Create a group of child servers:
$ sudo /etc/NX/nxserver --servergroupadd SERVERGROUPNAME

Forbid a specific system group access to that group of servers

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVERGROUPNAME --value no --group SYSTEMGROUPNAME

or forbid a specific user:

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVERGROUPNAME --value no --user USERNAME

Forbid all system groups except one group to access a specific group of servers

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVERGROUPNAME --value no

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVERGROUPNAME --value yes --group SYSTEMGROUPRNAME

Forbid all users except one user to access a specific group of servers

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVERGROUPNAME --value no

$ sudo /etc/NX/nxserver --ruleadd --class server --type SERVERGROUPNAME --value yes --user USERNAME

To use NoMachine groups, create a NoMachine group of users and assign users to this group:

$ sudo /etc/NX/nxserver --groupadd GROUPNAME

$ sudo /etc/NX/nxserver --useredit USERNAME --group GROUPNAME

Then apply any of the rules above to the NoMachine group.

 

Windows
Open a CMD console as administrator and execute the following commands.

> cd C:\Program files (x86)\NoMachine\bin\

Create a group of child servers:

>  nxserver --servergroupadd SERVERGROUPNAME

Create a NoMachine group of users and assign users to this group:
>  nxserver --groupadd GROUPNAME

>  nxserver --useredit USERNAME --group GROUPNAME

Forbid a specific NoMachine group of users access to that group of servers

>  nxserver --ruleadd --class server --type SERVERGROUPNAME --value no --group SYSTEMGROUPNAME

or forbid a specific user:

>  nxserver --ruleadd --class server --type SERVERGROUPNAME --value no --user USERNAME

Forbid all NoMachine groups except one group to access a specific group of servers

>  nxserver --ruleadd --class server --type SERVERGROUPNAME --value no

>  nxserver --ruleadd --class server --type SERVERGROUPNAME --value yes --group GROUPRNAME

Forbid all users except one user to access a specific group of servers

>  nxserver --ruleadd --class server --type SERVERGROUPNAME --value no

>  nxserver --ruleadd --class server --type SERVERGROUPNAME --value yes --user USERNAME

 

3.6. Set-up the HA failover cluster (optional)

Once the multi-server setup is completed, you can add a second Cloud Server to the first one and create a High Availability failover cluster. The second Cloud Server is passive and monitors the first one. It will take the role of the first Cloud Server when this for some reasons goes down.

Let's call CS1 the first Cloud Server and CS2 the second Cloud Server.

 

Linux and macOS
Execute from a terminal:

$ sudo /etc/NX/nxserver --clusteradd --local <local IP of CS1> --shared <IP of the cluster host>
$ sudo /etc/NX/nxserver --clusteradd <local IP of CS2>

Then restart CS1 and CS2. 
Firstly on CS1, then on CS2 execute: 

$ sudo /etc/NX/nxserver  --restart

 

Windows
On CS1, open a CMD console as administrator and execute:

> cd C:\Program files (x86)\NoMachine\bin\

> nxserver  <local IP of CS1> --shared <IP of the cluster host>

> nxserver --clusteradd <local IP of CS2>

Then restart CS1 and CS2. 
Firstly on CS1, then on CS2 execute: 


> nxserver --restart

 

4. Supported Authentication Methods and known limitations

Authentication methods supported

Authentication method NX protocol SSH protocol
Login with user's password yes yes
Login with SSH private key yes yes
Login with SSH private key provided by SSH agent - yes
Login with SSH private key stored on a smart card - yes
Login with Kerberos ticket on client side yes yes
Support for SSH agent forwarding no yes
Support for Kerberos tickets authentication forwarding yes yes
Support for two-factor authentication yes yes

 

Known limitations

There are known limitations which affect Windows hosts joined in a Active Directory domain when domain accounts are used to connect to the Cloud Server and/or to the Enterprise Desktops. In this context, not all the available authentications methods can be used due to Windows preventing the creation of the necessary user's security context.

In the following scenarios:

Cloud Server: Windows
Enterprise Desktop: Linux/macOS
Account type: domain

Cloud Server: Linux/macOS
Enterprise Desktop: Windows
Account type: domain

Cloud Server: Windows
Enterprise Desktop: Windows
Account type: domain

the authentication methods that can be used to login to the Windows host are:

Authentication method NX protocol SSH protocol
Login with user's password yes yes
Login with SSH private key NO NO
Login with SSH private key provided by SSH agent - NO
Login with SSH private key stored on a smart card - NO
Login with Kerberos ticket on client side yes NO


Authentication forwarding
There aren't known limitations in authentication methods related strictly to forwarding method.

However, it's important to remember that when system authentication method is in use (forward method 'system'), authentication is done twice, first on Cloud Server and then on the Enterprise Desktop. This means that when key authentication is used, the public key needs to be added on both Cloud Server and Enterprise Desktop host.
 

5. Our main test environments

NoMachine integrates seamlessly in the following environments with standard configurations. Connections by NX protocol, SSH protocol and via web are all supported.
We regularly test NoMachine in the following environments:

1) Active Directory:

Windows 2016 server AD controller

Windows 10 client

RHEL 8 


2) Kerberos:
    Ubuntu 15.04 - KDC
    Ubuntu 15.04 - client  


3) LDAP:
    Ubuntu 15.04 - server
    Ubuntu 15.04 - client  
    RHEL7 - client


4) Network Information Service (NIS)
    Ubuntu 19.04 - server
    Ubuntu 19.04 - client x2

5) Google Authenticator Two-Factor Authentication::
    Kubuntu 17.10

6) Duo Security Two-Factor Authentication:
    Ubuntu 18.04
    Windows 10
    macOS

7)  Squid HTTP proxy with password authentication enabled

8) Fail2Ban
    Ubuntu

We tested also some specific environments like:  NGINX reverse proxy for HTTP, OATH Toolkit  for OTP passwords and Okta MFA.
As a note, CA public keys for key-based authentication for connections by SSH protocol are not yet supported.

 

6. FAQs

How can I protect my corporate workstations further?
A common solution used already by some of our customers is to place the Cloud Server in a DMZ , open connection from the Internet to it and allow connections to workstations in the corporate network only from the Cloud Server host.

Which user accounts are necessary?  

The user needs to have a valid account on the Cloud Server host and on the Enterprise Desktop. The Username must be the same, password can be different but not empty. The account can be a local account or a LDAP account or an AD account. NoMachine doesn't check if the source of user account information is for example LDAP or local account database.
 Be sure to configure the login in advance. To check that everything works correctly, log-in with the same username to the Cloud Server host and to the Enterprise Desktop host by other means than NoMachine. For example if the Enterprise Desktop is on macOS or Linux or Windows 10 with OpenSSH installed, you can try via SSH.

Do I need to create a local account on each machine which will be part of a Cloud Server setup?
If machines are part of the same AD domain or they are connected to the same LDAP directory, no.

What can I do if the Cloud Server host and the Enterprise Desktop host are not in the same AD domain?
In the case the Cloud Server is joined to the domain but the Enterprise Desktop is not domain-joined, it's necessary to have an account with the same username, valid for both machines.

Forward methods 'tunnel' and 'token' will work out of the box. Forward method 'system' requires that the password is also the same for both machines.

If the Cloud Server (domain-joined) is on Windows, it's necessary to use the short username instead than the full domain username (username@domain).

Is there a difference in configuring NoMachine on Azure Domain Services or on Active Domain?
No, there isn’t. In both cases, you need to ensure that the user can authenticate with the same account on the Cloud Server and the Enterprise Desktop. Furthermore the necessary ports must be open in the firewall to allow NoMachine connections (see section Default TCP PORTS used by NoMachine).

Can I install NoMachine Cloud Server in a hosted virtual infrastructure like for example Microsoft Azure, Amazon Web Services or Google Cloud?
Yes, you can. We prepared some tutorials for basic configurations:
https://www.nomachine.com/accessing-your-remote-desktop-on-google-cloud-platform-via-nomachine
https://www.nomachine.com/accessing-your-remote-linux-desktop-on-amazon-elastic-compute-cloud-via-NoMachine
https://www.nomachine.com/accessing-your-remote-desktop-on-azure-via-nomachine

Can I install the Cloud Server and the Enterprise Desktop on premise and authenticate against Azure AD?
We are working on it :-)

Is Two-factor and Multi-factor authentication supported?
Two-factor authentication and MFA are supported for client connections by both the NX and the SSH protocols.
You can find here some examples for Cloud Server on Linux: https://www.nomachine.com/AR12L00828

Does NoMachine Cloud Server work with Duo Security and PAM-OKTA ?
NoMachine should be able to work seamlessly with Duo Security and PAM-OKTA. 
Based on tests in our labs made on macOS and Linux, NoMachine integrates seamlessly with DUO in its default configuration.

Can I use Yubico authentication with NoMachine on Linux?
Yes, you can. Instructions are available here:
https://www.nomachine.com/AR12Q01064

Is UF2 authentication with YubiKey supported?
At the moment it's not supported. Yubikey two-factor authentication cannot be used to login to the remote host by NoMachine. It requires the implementation of https://www.nomachine.com/FR07N03138.

It's possible instead to use USB forwarding to make the Yubikey available in the remote session and use it.

Is biometric identification supported?
No, NoMachine doesn’t support biometric identification like fingerprint, or retina scan or voice or face authentication.

What is the ‘nx’ user and why does NoMachine create it?
The 'nx' user is a reserved account for handling internal operations of the NoMachine server. It’s necessary that this account belongs to a system group with administrative privileges. It's created during the installation of a NoMachine server package

The nx account, which is also a hidden account, cannot be used by users (privileged or not) to log-in directly to the system (e.g. via the login window or via a SSH client that is not NoMachine). The nx account cannot be deleted from the system or the NoMachine server will be no longer operational.

Which are the requirements for using UDP for multimedia data?
UDP communication is supported only with client connections by NX protocol. UDP uses by default a range of ports between 4011 and 4999.
Ports must be open on each Enterprise Desktop federated under the Cloud Server. If these ports are not available, multimedia traffic will fall back to TCP communication. Note that UDP communication is always disabled when using SSH protocol.

UDP can be disabled on client side, in the connection settings -> NX protocol -> Advanced panel.