Skip to main content



How can we help you?


Druva Documentation

Firewall rules required between inSync Master or Storage Node and Edge server - Case Study

Heads up!

We've transitioned to a new documentation portal to serve you better. Access the latest content by clicking here.

This article applies to:

  • Product edition: inSync On-Premise


There might be a scenario where an inSync Edge server in a demilitarized zone (DMZ) outside the organization's firewall acts as a gateway to the public internet. Here, rules must be specified for the firewall located between the inSync Master Server/Storage Node and the inSync Edge server.


Data flow that warrants firewall rules


Explained below is the logical data flow from inSync Client to inSync Master/Node server via inSync Edge server:



  • The inSync Master Server and Storage Nodes maintain a persistent outbound connection to inSync Edge Server on TCP port which is configured as a backup/sync port. (By default TCP port 443)
  • Similarly, inSync Client maintains a persistent connection with inSync Edge Server over backup/sync port.
  • By default, the Edge Server has self-signed SSL certificates loaded. Administrators can also choose to load their own certificates for their environment.
  • When the inSync Master connects with the inSync Edge server, inSync uses a shared unique key between the inSync Master and the Edge Server to authenticate the connection. This ensures that only trusted application acts as the Edge Server or the inSync Master. Once the authentication is successful, a persistent outbound connection is established from the inSync Master to the inSync Edge Server. The same authentication mechanism is used between the Storage Node and the Edge Server.
  • All communication between various components are encrypted by using TLS 1.2 encryption.
  • When inSync Client users who are outside the enterprise network try to connect with the Edge Server, the inSync Client checks for certificate fingerprint and also refers to the root CA repository to verify the Edge Server identity. If the certificate fingerprint check fails, the inSync Client stops communicating with the Edge Server.
  • When the Edge server receives a request from a device, a parameter validation is performed. Only the requests having the right parameters in the correct format are filtered through and sent to inSync Server and storage node for the authentication. This is applicable to all endpoints on Windows, MAC, Linux, iOS, Android, and Windows Phone 8/8.1 platform.
  • Once the inSync Client is authenticated successfully, the Edge Server creates a secure tunnel from the inSync Client to the inSync Server or the storage node.
  • Edge server never initiates a connection to the inSync Server or Storage Node. The inSync Server and Storage Node initiates this connection with the Edge Server as part of reverse RPC communication method. This prevents any other devices from masquerading as the Edge Server.
  • When Edge server receives data packets which need to be relayed to inSync server, inSync server initiates another outbound connection to the edge server other than already established persistent connection. Thus, the data gets handed over to the server via the new connection which got created.


From the data flow discussion and the complementing image above, the following firewall rules can be deemed necessary:

For Firewall 1:

  • Outbound rule from Master Server to Edge server on TCP backup/Sync port configured.
  • Outbound rule from Storage Node server  to Edge server on TCP backup/Sync port configured.

For Firewall 2:

  • Inbound rule from Client to Edge server on TCP backup/Sync port configured.