Restrictions on firewalls can be made in many different ways depending on a shops rules and application specifics. One way to manage a firewall is via port restrictions. By creating a port restriction allows the firewall to manage TCP/IP traffic through a specific port or set of ports. This rule can be configured to allow inbound, outbound or inbound/outbound traffic through the firewall.
The Attunity environment can make use of such restrictions. In a non-restrictive environment, data requests via an application connection are initially made to the Attunity IRPCD Daemon. The daemon either starts a server or assigns the connection to an existing server running on a a specific port. Packets are then passed via TCP/IP to the application via this I/P:PORT connection.
In a restrictive environment a firewall that sets a restriction on ports could, if not configured properly, deny an application to connect to an Attunity daemon and server. For this reason the Attunity workspace has a parameter which can be configured to coincide with a rule built on a firewall/port restriction. By coding a serverPortsRange parameter on a workspace forces the IRPCD daemon to start an Attunity server process on those ports only in the range. This range needs to be applied to all workspaces including hidden workspaces such as ACADMIN. The range at the firewall must meet or exceed the range used in the Attunity configuration. The range can be coded either as the entire range for each workspace or each workspace can use a subset of the total given range.

For example:

The firewall has 50 ports opened up for inbound/outbound traffic via the Attunity product 8000-8049. I have four workspaces defined and one hidden ACADMIN workspace. I can add in the parameter for each workspace as follows to use the entire range.


I can also assign a specific range for each workspace if I choose to and servers for each will only be started in this subset:

ACADMIN ...serverPortsRange="8000-8009"
Navigator.. serverPortsRange="8010-8019"

Note also, the workspace server configuration must also be set so the resource limitation does not exceed the number of ports available for theses workspaces.


When firewall restrictions are used in this manner there are a couple of things that need to be made note of for this configuration:

1.) The Attunity product does NOT reserve the ports on a specific machine. The parameter is a boundary for the IRPCD daemon to work within. There may be other machine processes that use ports within the range.

2.) Any firewall restriction that is enforced will limit the scalable growth of an application. If there is an expected growth within an application both the firewall and our daemon/workspace environment need to be configured to include this growth. One example might be rolling out an application to different offices within your organization. If a new office is expected to be rolled out then the number of application connections needs to be calculated and the number of additional ports needs to be opened up at the firewall and configured in the Attunity workspaces.

3.) Both the firewall and the daemon/workspace configuration should be configured at the same time so the values are the same for each product. The Attunity daemon/server environment is not a dynamic setting within the configuration. The environment needs to be reloaded and refreshed for the changes to occur. If an extended range is configured in the Attunity environment this extended range must also be defined the in firewall rule so as not to cause and error in the application.

4.) These values and restrictions work in conjunction with any network address translation that may also be configured at the firewall. Connecitons via the Attunity product can be made using the parameter "firewallProtocol=..." in a client connection and the ports restriction interacts with these settings at the translation.