|TS484: Configuring Helix 5.0–5.2.1 for Access through a Firewall|
This configuration note applies to Helix 5.0–5.2.1 only. The information below does not apply to Helix 5.3 or later.
A Helix Client (5.0-5.2) can't reliably connect to a Helix Server that is behind a firewall.
A firewall, which segments a network into two physical sub networks, restricts unauthorized access to internal networks. A firewall acts as the gateway between the two networks; one side of the firewall connects to a public network (e.g. the Internet) and the other connects to a private network. When a request is made for data to pass through the firewall, the data is "filtered" and if the necessary criteria are met, traffic is allowed. The absence of those criteria causes the firewall to block the communication. When data is allowed to pass through the firewall, a port is opened between the two networks and the data passes through.
In order for a Helix Client to access a collection hosted by a Helix Server that is protected by a firewall, the network manager must configure the firewall to allow the required traffic. Communication between Helix Server and Client is as follows. By default, Helix Server listens for incoming requests on TCP port number 10850. (This port number is stored in a resource in the Helix applications that can be changed using a resource editor.) When a request is made (on port 10850) the Helix Server will reply via one or more streams of data, each requiring its own port. These port numbers are randomly assigned, but are all initiated by Helix Server.
Given the default configuration, the firewall must be configured as follows...
These two settings will allow a Helix Client to access a Helix Server that is on a network protected by a firewall.
When the Helix Client initiates communication to the Helix Server, the client uses port 10850; when the Helix Server initiates communication to the client, the server uses dynamic port numbers for both sending to and receiving responses from the client. These dynamic port numbers are usually (but not necessarily) greater than 1023. Therefore, if the Helix Client is behind a firewall, attempts by the Server to contact the Client will be turned away by the firewall if the port is not set to allow unsolicited connections. Since port assignment in this direction is random, we can not predict which port requests will come in on, and unless all ports are open (which would be the effective equivalent of turning the firewall off) there is a chance that the data will be rejected. If this happens, Helix Server will assume (after a timeout period) that the Client has crashed and terminate the connection completely. Therefore you can see that passing Helix via TCP/IP will only work properly if Helix Client is not behind a firewall. We acknowledge that this is a serious limitation and plan to address it in a future release.
|Helix Client and macOS Personal Firewall||
OK, now that we've said you can't use a Helix Client that is behind a firewall, we'll turn around and say you really can. The problem from a traditional firewall standpoint is that you never know which ports a particular Helix Client will attempt to use. However, with the introduction of the personal firewall in macOS 10.2, it is possible for a Mac running Helix Client to be responsible for its own firewall, making it much more convenient to 'punch a hole' in the firewall for Helix TCP/IP traffic.
|How can I be sure this is my problem?||
The typical symptom of a Client behind a firewall is that the Client is able to successfully connect to the Server, but opening a list results in Helix's "spinning arrow" cursor. You should also see that popup menus on entry forms never fill in, remaining greyed out indefinitely. Lists and popup menus are asynchronous processes, and Helix TCP/IP uses one of its additional ports for each such process. So, if your lists and popup menus don't work, yo can safely conclude that your Client is behind a firewall.
|Configuring macOS Firewall||
The simplest solution is to temporarily turn off the firewall in the Sharing preference pane. To keep the macOS Firewall active, follow these steps to add the necessary ports:
You should now be able to connect to a Helix Server without difficulty. If it does not seem to be working, recheck the Host info and the information you entered into the Firewall tab.
Final notes: You can change the firewall settings 'on the fly' while connected to a Helix Server. Changes take effect immediately when you click OK.
You don't have to create a new port mapping entry each time you use Helix Client. Just update the port range with the new xxxxx & yyyyy values.
If it doesn't seem to be working, try temporarily turning the firewall off altogether. If Helix Client still doesn't work, there is something else blocking your access.