Linux Hub Requirements

System Requirements

This chapter provides a list of requirements for the Linux system on which the Nectar Endpoint Client will be installed as a Hub. 

Note: it is recommended by Nectar that all hubs be Linux.

Platform Requirements

Nectar Endpoint Client for Linux Hub is supported for the following operating systems:

• Red Hat Enterprise Linux (RHEL9) / Rocky Linux / Oracle Linux / AlmaLinux 8 or 9
• Debian 12
• Ubuntu 22, 23 or 24

Hardware

The platform hardware requirements vary depending on the number of virtual endpoints that have been licensed for the agent. The following are the minimum platform requirements required for installation of a Nectar Endpoint Client on a Linux system:

Ports and Protocols

The following is a list of ports and protocols used by the Nectar Endpoint Client. If the agent will be running behind a firewall, the following ports should be open in your firewall configuration to allow the agent to function properly.

Local Ports

Remote Ports

* Default port number.

Firewall Configuration

The following sections provide general guidelines for configuring the Linux firewall to open the ports required by the Agent. For more detailed information about firewall configuration, consult the firewalld or iptables documentation.

Using firewalld 

The following firewalld command can be used to implement the required firewall rules in RHEL etc, while logged in as 'root':

firewall-cmd --permanent --zone=[default_zone] --add-port=[port_number]/[tcp|udp]

For example:

firewall-cmd --permanent --zone=public --add-port=5060/udp

success

Multiple ports can be opened with one command. For example:

firewall-cmd --permanent --zone=public --add-port=5060/tcp --add-port=5060/udp --add-port=40000/tcp --add-port=26022/tcp --add-port=29999-50000/udp

success

After configuring all the necessary ports, enter the following command to reload the firewall service:

firewall-cmd –reload

Using iptables

The following iptables commands can be used to implement the required firewall rules in older versions of RHEL/CentOS, while logged in as 'root':

# inbound TCP management-domain connections

iptables -A INPUT -p tcp --dport 40000 -j ACCEPT

# inbound ICMP messages

iptables -A INPUT -p icmp -j ACCEPT

# inbound UDP SIP messages

iptables -A INPUT -p udp --dport 5060 -j ACCEPT

# inbound TCP SIP messages

iptables -A INPUT -p tcp --dport 5060 -j ACCEPT

# inbound UDP RTP media and UDP P2P probes

iptables -A INPUT -p udp --dport 29999:50000 -j ACCEPT

# outbound TCP connections to Controller SCP

iptables -A OUTPUT -p tcp --dport 26002 -j ACCEPT

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT ACCEPT

service iptables restart

iptables: Setting chains to policy ACCEPT: filter [ OK ]

iptables: Flushing firewall rules: [ OK ]

iptables: Unloading modules: [ OK ]

iptables: Applying firewall rules: [ OK ]

Test Interface IP Addressing

When running an active test on an agent, it is necessary to select a specific local interface and IP address to be used as the test interface. It is therefore strongly recommended that a static IP address be assigned to any network interface that will be used to run tests, rather than using DHCP to assign addresses automatically. If dynamic addressing is used and a test interface IP address changes, it will cause all tests currently running on the old IP address to fail, along with any tests scheduled to run using the old IP address.

Dynamic or static IP assignment can be used for the management domain interface used to communicate with the Controller if it is a dedicated interface that will not be used to run tests. For any interface that will be used as a test interface, static IP addressing is advised