This blog is dedicated to SharePoint on premise installations of the Hawkeye Data Collector in regards to Firewalls.

The Hawkeye SharePoint data collector communicates to the cloud in a couple of ways.

It talks to what we call the discovery API for commands, to register itself and request upstream endpoints to live events and workflow definitions. In production these urls are:

1. https://discovery.hawkeyecloud.com (port 443)
2. https://wus-discovery.hawkeyecloud.com (port 443)
3. https://neu-discovery.hawkeyecloud.com (port 443)

For upstream communication Nintex talks directly to azure storage and event hubs directly. Azure storage will again use port 443 on urls similar to this one https://<storage<https://%3cstorage> account name>.blob.core.windows.net/.

Event hubs can use a couple of different methods. The urls will look something like this sb://<event hub name>.servicebus.windows.net/. It will initially try to connect using AMQP over ports 5671 and 5672. If these are closed it will try TCP ports 9350 to 9354. If these are closed it will fall back to https over port 443 (this is slower).

You will notice that setting static IP addresses for the firewall are met a problem on the upstream communication connection. The address pool is large and dynamic for azure. 

Example IP Address from the Azure Communication 

104.42.99.205
104.42.102.43
104.42.103.33
40.78.24.223
40.78.24.223
40.78.26.96
40.78.29.8
23.99.86.71
23.99.86.71
23.99.80.74
23.99.80.74
23.99.87.134
23.99.87.137
23.99.87.137
23.99.86.142

Summery 

It is not possible for us to provide all IP ranges, as this service point can expand depending on usage for the Microsoft Azure platform. This is why it becomes important to have Application profile on a URL for a firewall rule rather then explicit IP address. This can be a problem for older firewall kit/software.