Netreo On-Premise Virtual Appliance Connectivity Preparation

Introduction

The purpose of this document is to give technical personnel some basic guidelines on the connectivity requirements of Netreo to speed the implementation process. If you have any questions, please contact Netreo Support at support@netreo.com for an immediate response. 

This document cannot be comprehensive, as custom configurations may add additional connectivity requirements that are unique to a customer’s environment. For additional documentation on firewall requirements, please see Firewall Requirements. Also see Deployment Specifications for more details on protocols and polling methods.

The basic architecture used is that local information is collected through the use of one or more dedicated virtual appliances in the customer environment. Data can be collected either by the primary appliance (acting as both a UI server and a service engine) or one or more dedicated service engines (SE). SEs can be configured to collect polling/statistical data, NetFlow and traffic data, or syslog data - or a combination of these. The exact configuration of a particular SE will dictate the connectivity requirements for it, and how much bandwidth it will consume.

General Appliance Firewall Requirements

Basic IP connectivity to managed devices is necessary to monitor the systems for availability in Netreo. This basic level of IP connectivity requires that Netreo be able to Ping (ICMP ECHO) the managed devices. In addition to Ping, Netreo will need connectivity to a DNS (internal) server, as well as an NTP (external or internal) server so that name/IP resolution is possible and so that Netreo’s clock can remain synchronized. 

• ICMP (echo, echo-reply, ttl exceeded) to all monitored devices from the SE.
• NOTE: If ICMP is not an option for particular devices, a Netreo SE can be configured to use any TCP port to determine device availability.
• DNS: Port TCP/UDP/53 (originating from the SE to any/all internal DNS servers).
• NTP: Port UDP/123 (originating from the SE to any/all internal NTP servers).
• For UI access to the primary appliance: From internal management systems/users to destination TCP/443 on the SE.
• For UI access to the SE (only required for troubleshooting and initial deployment): From internal management systems/users to destination TCP/443 on the SE.

For remote technical support and customization, allow:

• FQDN: charon.netreo.net
• Port: TCP/443

In unusual cases, the system can be configured to use an alternate port instead by contacting Netreo Support. Check the Systems Diagnostics page for the configured port and protocol on your system if you have made this change.

(Application-aware firewalls will need to configure this as SSL/TLS and OpenVPN.)

For automatic Netreo licensing, allow:

• FQDN: activation.netreo.net
• Port: TCP/443

For software update support, allow:

• FQDN: updates.netreo.net
• Port: TCP/80
• Port: TCP/443

Netreo Mobile and Cloud Features

Netreo uses a wide variety of dynamic technologies to route and assign users to the best or closest cloud-hosted server, so it is not possible to restrict access to a group of IP addresses. Netreo recommends allowing outbound access for SSL/TLS or HTTPS on port 443. If your firewall allows you to restrict access by domain name, you can use the following destinations (all are port TCP/443):

• *.api.netreo.com
• *.rr.netreo.com

For geocoding information used by the Netreo geographic map feature, allow outbound access from the primary appliance to:

• api.geonames.org
• dev.virtualearth.net

Alerting

Netreo sends various kinds of alert notifications that can be configured by the customer. Each of these alerts requires connectivity from the primary appliance.

• Email alerts require SMTP, which uses destination port TCP/25, TCP/587, or TCP/465 on the mail server (depending on your mail server configuration), originating from the primary appliance. An SMTP proxy can be configured if you do not wish to allow direct outbound SMTP access to outside servers (for example, directly alerting to gmail or to a cellular messaging system). However, the use of an SMTP relay can create a single point of failure for email-based alarms, and it is recommended that you configure alternative alerting mechanisms to handle these cases when using a relay.
• Mobile device push notifications: TCP/443 from the primary appliance to *.api.netreo.com and api.netreo.com. The large number of potential end points used for redundancy and load balancing mean a specific list of IP addresses cannot be provided.
• Webhook-style notifications (Slack, Teams, OpsGenie, ITSM ticket creation, etc.) typically require TCP/443 from the primary appliance to your API endpoint address. Please consult the documentation for those services to confirm the destinations required.

Network Devices

(Routers, switches, UPS, load balancers, wireless, firewalls, etc.)

Netreo uses SNMP to collect this data. Your devices should be configured to respond to SNMP from the IP address of the Netreo appliance. Only read-only access is required. Netreo recommends SNMPv2c for best performance, though all versions of SNMP are supported. 

Netreo also incorporates a device configuration manager used for backing up device configurations and tracking changes. Netreo will need privileged login credentials to these devices in order to use the configuration management features. See the “Configuration Management” section in this document for more information on this capability.

Firewall Implications:

• SNMP:
  • Port UDP/161 for polled data collection.
• SNMP Traps:
  • UDP/162 (originating from the device to Netreo SE).
• Special Cases:
  • Palo Alto firewall: Hybrid SNMP UDP/161 and SSH TCP/22 for full instance monitoring.

Windows Servers 

WMI, WinRM and PowerShell are protocols used to collect data from Windows servers. WMI is enabled by default on all versions of Windows since 2003. WinRM is installed by default on Windows servers since 2008, but must be enabled manually in early versions. The primary difference is that WinRM uses a single port for data collection - which is much simpler to configure if the traffic has to traverse a firewall.

Either of these requires an account with local administrator privileges or DCOM permissions on the device to be managed. See Windows Device Monitoring and Management for more information on how to use non-administrator accounts to access Windows statistics.

This connectivity is also required for collecting Windows Event Logs and service management and monitoring.

Firewall Implications:

• WMI:
  • Destination Port TCP/135 on the device to be managed, originating from the SE, and all high ports (1024-65535), bi-directionally.
• WinRM:
  • Destination Port TCP/5985 or TCP/5986, originating from the SE.

For more information about WinRM ports, see Windows Device Monitoring and Management.

MS SQL

Most statistical data about the health and performance of MS SQL is collected via WMI or WinRM using the standard connectivity detailed for Windows Servers (shown above). 

However, Netreo also supports custom monitoring via SQL queries directly to the database. In these cases, connectivity to the SQL port(s) from the SE will be required.

Firewall Implications:

• WMI:
  • Destination Port TCP/135 on the device to be managed, originating from the SE, and all high ports (1024-65535), bi-directionally.
• WinRM:
  • Destination Port TCP/5985 and TCP/5986, originating from the SE.
• SQL:
  • Default instance - destination Port TCP/1433, TCP/1434, and UDP/1434 originating from the SE.
  • Custom or named instances will require access to the destination port specified in the database, or to TCP/1024-65535 for dynamic named instances.

Linux/Unix Servers 

For these devices Netreo uses SNMP and the Host Resources MIB. Most of these servers include a package called “net-snmp” to provide SNMP access for management systems. Make sure this package (or similar) is installed and the agent (snmpd) is running. 

Firewall Implications:

• SNMP: Destination Port UDP/161 on the device to be managed, originating from the SE, for polled data collection.
• SNMP Traps: Destination port UDP/162 (originating from the device to Netreo SE).
• Special Cases:
  • SSH-based Linux Polling: Destination Port TCP/22 from the Netreo SE.
  • Note: SSH-based Linux polling is not recommended unless no alternatives exist.

VMware vCenter 

To collect metrics for virtual resources in vCenter, Netreo uses the APIs that VMware has made available for that purpose.

Firewall Implications:

• Destination Port TCP/443 on the vCenter to be managed, originating from the SE.

Cloud (AWS, Azure, GCP) 

To collect metrics for and automatically discover resources in cloud providers, Netreo uses the APIs they have each made available for that purpose. This requires outbound access from Netreo to those cloud API endpoints, usually on TCP/443. Please consult your cloud provider documentation for a current list of those API endpoints.

Firewall Implications:

• Destination Port TCP/443 (or another port) on the cloud provider API to be managed, originating from the primary appliance.

Syslog

Syslog is a protocol used to push messages on demand from devices under management into Netreo. The biggest issue with syslog is that it can generate a large number of messages, obscuring important details with routine or trivial ones.

Netreo recommends configuring syslog on critical infrastructure devices, but that you configure those devices to limit the messages sent to warning level or higher.

Recommendations:

• Netreo will collect any syslog messages sent to it, but will not generate alerts for those messages unless you create syslog alert rules to do so.
• It's good practice to restrict the syslogs being sent to warning or more severe levels.
• Netreo recommends against sending syslogs from firewalls into Netreo, as it is not designed to be a dedicated high-volume log-processing tool.

Firewall Implications:

• Syslog uses destination port UDP/514, originating from the device to the SE.

Configuration Management/Looking Glass

Netreo provides device configuration management (push/pull) as well as realtime command execution (looking glass and active response) to devices.

Netreo can use either SSH or Telnet to connect to CLI devices for these features. Where possible, Netreo recommends the use of SSH, since it includes encryption functionality. Telnet is insecure and should only be used if the device under management does not support SSH v2. Netreo does not support the SSH user-documentation protocol, as it is insecure and obsolete.

Recommendations:

• Use SSH where supported by the device under management.
• Do not use Telnet unless no alternatives exist, as it is insecure.
• If your environment uses a centralized login manager such as Radius or TACACS for authentication, use a dedicated Netreo account to manage access.
• If you are using filters or access lists to restrict CLI access, be sure to include the specific IP address of the Netreo SE.

Firewall Implications:

• SSH requires destination port TCP/22 on the device to be managed, originating from the SE
• Telnet requires destination port TCP/23 on the device to be managed, originating from the SE

Synthetic Checks 

Netreo supports synthetic application tests for web applications as well as for email servers, to simulate user traffic and measure response time and functionality. Email checks may involve sending mail out to servers on the internet (or locally) and retrieving that mail from a local or remote server. Your exact configuration will dictate which firewall rules are required. These checks can be initiated from the primary appliance, a deployed SE, or via a series of “remote reflectors” that Netreo maintains in data centers around the world.

Firewall Implications:

• For email synthetic checks:
  • Sending requires SMTP, which uses destination port TCP/25, TCP/587 or TCP/465 on the mail server (depending on your mail server configuration), originating from the SE.
  • Receiving requires IMAP or POP, which uses a destination port based on your configuration. The most common ports are TCP/993 (IMAP) or TCP/995 (POP3) on the mail server, originating from the SE (other ports are possible depending on configuration).
• Web synthetic checks require destination port TCP/443 (or less commonly, TCP/80, or other custom web application ports) on the devices to be monitored, originating from the SE.
• Synthetic checks using remote reflectors will also need TCP/443 access to rr.netreo.com and *.rr.netreo.com. The large number of potential end points used for redundancy and load balancing mean a specific list of IP addresses cannot be provided.

NetFlow/sFlow/IPFIX

Netreo supports NetFlow (version 5 or 9), sFlow, cFlow, and IPFIX export from devices for traffic and protocol analysis and volume information. Flow export technologies such as these cause network devices (typically layer 3 devices like routers) to send "accounting level" information to Netreo (including source and destination address, port, protocol and volume data) for reporting purposes.

When configuring flow technologies such as these, the goal is to configure the fewest number of exporters possible while still ensuring that Netreo can collect data on all the required traffic. Netreo automatically detects and processes duplicate flows to avoid creating incorrect traffic counts, but this is not always possible in complex network configurations (especially those involving NAT/PAT).

Firewall Implications:

• We require NetFlow, cFlow and IPFIX to be sent to destination port UDP/2055 on the SE.
• sFlow should be sent to destination port UDP/2056 on the SE.

Oracle SQL (Oracle, MySQL)

Netreo supports data collection from these systems with a combination of SNMP or WMI/WinRM (depending on host OS) and direct connections to the SQL server. Connectivity from the SE to the SQL server on the applicable SQL port(s) is required for this monitoring.

Application-Specific Monitors

Netreo supports the use of custom application monitors which will check the status and availability of applications by simulating user traffic or executing custom commands. These applications vary widely and the exact connectivity requirements may vary (e.g., to monitor a custom application running on port 12345, that port must be enabled from the SE to the device being monitored). 

Typical use of application-specific monitors include DNS, HTTPS, FTP, SMB, print queues, and custom applications unique to the customer environment.