This document details the network configuration required for successful operation of the Navitas Hub. It will cover all required ports and IP addresses, along with an explanation of which each is needed.

The following set of network rules are required for the hub to operate successfully.

In every case the network rule must allow egress for ANY source port; this is due to how Linux-based devices will randomly allocate source ports when opening new connections to prevent network clashes.

To validate network connectivity the Hub will ping one of the following IP addresses and send an ICMP packet. If no reply is received the device considers itself to be offline and will not function.

Note that if only some of the destination IP addresses are permitted then the device will behave erratically, and toggle between Online and Offline depending on whether or not the ICMP succeeded.

The Hub must be able to resolve CNAMEs in order to connect to the various IPs listed within this document. The DNS server is a configurable field within the Hub, with two options present for both the ‘LAN’ and ‘WAN’ network interfaces.

This table shows the default values shipped with the hub.

In order to accurately synchronize the time on the hub, the system will periodically reach out to an NTP server. As is standard practice, each of these CNAMEs will correspond to a pool of servers which are geographically distributed across the world for both latency and availability.

For that reason, we strongly recommend that firewall rules either implement CNAME-based rules or, in cases where that is not possible, allow all outbound traffic on port 123.

That said; if you wish to attempt to further restrict your firewall it is possible to acquire a snapshot of the current regional timeservers by issuing a command similar to ‘dig +short ntp.ubuntu.com’

In order to transmit temperature readings into the Navitas platform, the Hub must be able to connect to our IOT middleware platform.

Navitas Smart Pods make use of LoRaWAN to transmit data to the hub, which is subject to different Frequency Plans according to the country in which they are operating. Each frequency plan requires a distinct endpoint for communication, and so the following table includes all possible endpoints.

In most cases it is only required to allow access to the server that represents your local region, however for simplicity it may be advisable to allow access to all servers where possible.

Note:

While the IP addresses are provided, we would strongly recommend that any firewall rules are configured based on the CNAME rather than the IP address. As we evolve and improve our IOT platform it is likely that the IP addresses will change.

When following the setup-wizard within the hub, part of the flow will guide the installer through the process of adding Navitas Smart Pods to the system via the Digital Food Safety (DFS) platform. This is an optional step as pods can be added at any time via a direct HTTPS connection to DFS.

If this stage of the wizard is followed then, if the installer is still connected to the internet via the hub (e.g. via the wireless access point), then additional firewall rules need to be enabled.

These rules are not required if pods are added from an independent network after set-up.

Note:

While the IP addresses are provided, we would strongly recommend that any firewall rules are configured based on the CNAME rather than the IP address. As we evolve and improve our IOT platform it is likely that the IP addresses will change.

If there is a requirement to bind the firewall rules to the MAC address of the hub then the following is a guide to allow you to determine what values to use.

Note:

This guide relates to the current SKU only and previous SKUs have differences in how to extract the MAC address from the label. Please contact support if you are using an older model.

All Navitas Hubs have a label on the bottom side which looks similar to the following:

To extract the MAC address we use the Gateway Identifier (GWID) as the base and apply the following logic:

To extract the MAC address we use the Gateway Identifier (GWID) as the base and remove the ‘FFFF’ from the middle of the string; e.g. a84041ffff2a9256 becomes a840412a9256

To extract the MAC address we use the Gateway Identifier (GWID) as the base and remove the ‘FFFF’ from the middle of the string. Having done this, we must then add ‘2’ to the last hexadecimal octet; e.g. a84041ffff2a9256 becomes a840412a9258 (56 -> 58)

Note that as this is hexadecimal addition we must be careful of rollover during addition; e.g.

During typical set-up, the installer will connect to the hub via its local Access Point and perform any required network configuration via the in-built wizard.

It is important to note that during this period the installer’s laptop would typically be routing all traffic via the access point, and so a network inspection of the traffic originating from the hub may well show additional destination ip addresses and ports.

Similarly, if the Access Point is not removed from the installer laptop after the installation is completed then there is the possibility of that laptop reconnecting to the hub’s access point at a later date and further sending ‘unexpected’ traffic.

Once the hub is fully configured and accessible directly over the internal LAN or WLAN IP addresses then it is typically safe to disable the Access Point to avoid such situations from occurring and ensure that access to the device is appropriately controlled.

Where a CNAME is provided we strongly recommend that any firewall rules are based on the CNAME and not the IP address as the exact IP address may change over time.