Firewall Considerations for UIM Hub Tunnels
search cancel

Firewall Considerations for UIM Hub Tunnels


Article ID: 10564


Updated On:


DX Unified Infrastructure Management (Nimsoft / UIM)


This article contains both general and specific information regarding the configuration of firewall options as they relate specifically to UIM hub-to-hub tunnels.

The information contained in this article has been validated by customers and field engineers and will be updated as more information becomes available regarding specific configurations and/or firewall models.

Please note that this list is not intended to be an all-encompassing list; the specific firewall models listed here are not the only firewalls which may contain similar configuration options.  The options presented should be understood to be generally applicable to all environments, and questions about specific configuration settings should be directed to your firewall vendor.

UIM hub-to-hub tunnels employ a method of communication which, very broadly speaking, works as follows:

- tunnel clients establish connections to tunnel servers - a minimum of 3 SSL sessions at first, more will be created as needed

- SSL sessions are created when communication across a tunnel needs to occur, but the sessions are not fully closed when communication is complete.  Rather, the sessions go into a "suspended" state.

- Later, when further communication across the same path occurs, the session is re-opened (un-suspended) and re-used by the hub.

Many modern firewalls are considered "stateful" firewalls, and/or employ a technology known as "application awareness" - this is a method that firewalls use to control and manage traffic and sessions, and the details of how/why this works are beyond the scope of this document; but it is important to note that UIM tunnels and stateful/application-aware firewalls require special configuration on the firewall/network side in order to achieve tunnel stability.

If the settings on the firewall are not configured appropriately, a number of symptoms may occur in UIM, including, but not limited to:

- tunnel failures that can only be re-established by a restart of the hub(s)

- communication failures in Infrastructure Manager and Admin Console when trying to configure robots/probes across a tunnel

- intermittent unavailability of hubs and the robots underneath


Any version of UIM - stateful or application-aware firewall(s) in use between hubs which are connected via UIM tunnels.


The following section contains information regarding specific firewall configurations that we have encountered in the field, and will be updated as more information is gained. Again, this is not an all-encompassing list; many other firewall models are likely to share very similar configuration options.
Some SonicWall firewalls offer "port scan protection" features. This should be disabled where possible, as when the hub starts up, it immediately creates several local sessions on consecutively-numbered ports, and sometimes the firewall will mistakenly detect this activity as a port scan.
Juniper SRX:
Juniper SRX firewalls allow an "inactivity-timeout" setting to be specified per application; for the UIM hub traffic this timeout should be set to "never" in order to avoid the firewall expiring sessions that the hub was intending to re-use.
Palo Alto:
Palo Alto firewalls are stateful/state-aware firewalls and should be configured as follows: 
Idle connection timeout: 7200 -- this should be considered a minimum, higher is always better 
Max connection timeout: 7200 -- this should be considered a minimum, higher is always better
TCP Connection only : No application awareness (very important!)
Stonesoft firewalls are similar to Palo Alto firewalls in this regard and should be configured as described in the Palo Alto section above.
"Stateful Packet Inspection" should be disabled for the UIM hub traffic. This is likely to apply to other firewall types as well, as Stateful Packet Inspection is a common configuration option on many firewalls.
A note on SSL Decryption:
SSL Decryption is an option on many firewalls; it works by creating separate encrypted connections to the client and server so that the encrypted traffic can be decrypted and scanned before being re-encrypted and passed on. This option will cause UIM tunnels to fail and must be disabled. If this option is enabled, you will see a very specific "NO SHARED CIPHER" error related to the tunnel failure, either in the UIM hub logs or in the Tunnel Status section of the hub GUI.