|TCP/IP Networking in Helix Client/Server|
This note discusses the TCP/IP implementation in Helix 5.3 and later. If you are using 5.0 through 5.2.1 this link takes you to the correct page.
|Total Transparency in Helix 7||
Helix 7 (and later) users can almost certainly dispense with reading this technote, as connecting is now completely transparent. See the Client Connections in Helix 7.0 page for updated connection information, and come back here if you need additional technical information.
Beginning with version 5.3, Helix includes a robust implementation of TCP/IP that supports virtually all currently common network environments. DHCP, NAT, and Firewalls are now fully supported in both directions.
Setting up Helix’s TCP/IP implementation is very simple, and the few areas which may require network administrator intervention are mentioned below.
|Public and Private IP Addressing||
Clients on an intranet using private addressing can locate a local Helix Server either by entering the Server’s IP address or its Bonjour (aka Rendezvous or Zero Config) name.
If your Helix Server is on a computer with an assigned machine name (an A or CNAME record), you can simply enter the machine name to locate, whether connecting locally or remotely.
Helix 6.0 and later support Bonjour network identities. On your local network, just enter the Bonjour name of your Helix Server to establish a connection.
|Local Domain Searching||
If your Helix Server is on a computer with an assigned machine name (an A or CNAME record), you can enter the domain name in your TCP/IP configuration’s “search domains” field.
|Secondary IP Addressing||
Assign multiple IP addresses to a Helix Server and Clients will be able to connect to it through any of the addresses.
|Multiple Ethernet Interface Cards||
Assign a different IP address to each interface and Helix will be able to communicate through all of them.
Most wireless routers (such as Apple’s Airport Base Station) use DHCP/NAT to support wireless connections. The new implementation supports this transparently for Helix Client.
Helix Client: Since Helix Client initiates the connection, you shouldn’t have to open a port in your firewall. Truly zero-config. (Note: if your firewall is an external box attached to your network, it may be configured to deny Clients the ability to initiate traffic on port 10860. If this is the case, the firewall must be changed to allow Clients to initiate traffic on this port.)
Helix Server: Port 10860 must be open for Helix Clients to contact the Server. See this page for more on Server configuration.
For more information on firewalls, see this page from techtarget.com.
|DHCP Assigned IP Addresses||
Helix works with any IP address, regardless of how it is assigned. Of course, a dynamically assigned IP address (as is typical with DHCP configurations) will require extra effort for remote users to locate the Server.
|NAT (Network Address Translation)
(and Port Forwarding)
All that is required is that your router send (or "forward") incoming traffic that is on Helix’s designated TCP/IP port to the Helix Server’s assigned IP address.
|Which port does Helix communicate on?||
Helix 5.3 and higher use port 10860 for all Client/Server communications. Note that this is not the same as Helix 5.0-5.2, which used 10850, along with multiple random secondary ports.
|Changing the Port Assignment||
The PORT resource in Client and Server controls the port number. This resource consists of a single decimal word (DWRD type) that you can set to any value between 0 and 65535. To be a good IP citizen, only use numbers higher than 1023.
Helix Client does not need to have a matching PORT resource values to log in to a Server on the local network.
If the Client and Server do not have matching PORT resource values the remote client must specify the port as in this format: xxx.xxx.xxx.xxx:port. Domain name resolution is not supported in this configuration.
For information on editing the PORT resource, see this technote.
|Accessing Dynamically Addressed Servers||
Although having a static IP address is desirable, it is not required. Without a static IP address your remote Clients will (typically) need to contact you to find out the current IP address in order to locate your Server.
If none of those options are available, you can still provide your external Clients with an easy to remember DNS name through our add-on services. Whether you own your own domain or not, or use dynamic or static IP addressing, we can provide you with a DNS name resolution for your Server. Contact QSA Technical Support for more information.
Login passwords are encrypted, but the TCP/IP stream itself (including record data) is sent as unencoded/unencrypted data.
|TCP/IP vs AppleTalk||
Helix Server only supports one communications protocol at a time, so all Helix Clients accessing a single Server must all visit using the same protocol. AppleTalk support has been phased out in Helix 6 and we encourage all customers to switch to TCP/IP networking.
|Will Helix maintain its connection if I switch TCP/IP connections during a session?||
No. If you are running Helix Client and are connected to a Server, you should not switch connections without first logging out of the Server.
|Public vs Private IP Addresses||
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks:
010.000.000.000 - 010.255.255.255
If your IP Address is within one of those ranges, you are using private IP addressing. If you are uncertain, contact your network administrator or ISP.
A related note: an IP address starting with "169" is a “self-assigned” address. This address range is reserved and called the “link local” address range by IANA. It allows a computer to communicate using IP locally even if a DHCP server can’t be found. 169.*.*.* addresses are non-routable and typically mean that your computer is not connected to the network at all, but is in its own private world, unable to connect to other computers on the network. Typically this is an indicator of a faulty network connection.
To see your current public IP Address, click this link.
|Dynamic vs Fixed IP Addresss||
A fixed IP Address remains constant through any sort of hardware restart, ensuring that a web service (such as a web server) remains accessible over a long period of time. Most computers do not function as web servers and can use dynamic addressing.
Between ‘Public vs Private’ and ‘Dynamic vs Fixed’ addressing, there are four possible configurations for each ‘device’ on the internet. (Public/Dynamic, Public/Fixed, Private/Dynamic, and Private/Fixed.) A typical low-cost internet connection consists of one device (a router) that connects to the internet using a Public/Dynamic address with all computers on the local network using Private/Dynamic addresses, as controlled by the router. This setup typically requires very little setup; just plug your devices in and they work automatically.
Most inexpensive internet connections use dynamic addressing, with most ISPs making fixed addressing available as an extra-cost service. Your ISP can tell you which type of addressing you have, along with the cost for the fixed address option.
Although you can not rely on having a fixed address unless you have arranged one with your ISP, you may be able to take advantage of the fact that even though low-cost internet connections use dynamic addressing, they function as de facto fixed addresses. You can determine whether this is the case for your connection by observing the router’s public IP Address over a period of time. If it stays constant over the course of a week or two, it will probably remain constant until you turn the power off to your router.
To see your router’s current public IP Address, click this link.
|Why don’t you provide specific instructions on setting up a router for external Helix access?||
Because of the wide variety of network configurations and routers available, we do not give specific advice -- beyond what is discussed in this FAQ -- on configuring local networks. To do so would be to risk exposing your network to danger, as we can not possibly know all of the details about your specific hardware or about the other systems (both hardware and software) you run on your network. Our limited advice, applied in the wrong situation, could expose your company’s data to people who should not have access to it.
Because of these issues, we recommend that you take this FAQ page to your network administrator or somebody familiar with the specifics of your network. A qualified person -- familiar with your specific router -- can make certain your Helix traffic flows freely while keeping the rest of your network protected.
|Things Not Covered Here||
If we don’t specifically mention a network configuration here, we don’t know whether it works or not. Proxy servers, VPN, SSH, and many other IP routing techniques are available, but we are limited in our ability to test them all. We expect that most configurations will work, but if we can’t test it, we can’t tell you that it works with full confidence.
Unfortunately, because of the current situation we are in (every possible moment being dedicated to porting Helix to macOS and beyond) we aren’t able to investigate these other areas. We welcome your feedback, but please realize that we simply can not investigate these areas at this time.
|Where can I learn more about the internet and networking?||
Whatis?com is an excellent site that covers these issues in great detail.