Technical Educational Professional 3rd Party Contact Us

Overview Services techdb Issues Tips HMM FAQs Repair Search Feature Requests Bug Reports FTP

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 do require network administrator intervention are mentioned below.

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.
This enhancement (as compared to the Helix 5.0-5.2.1 implementation) means that you can use DHCP/NAT servers to distribute a single public IP address to all of your office's computers, while also giving external Clients access to the database.

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.
In the Helix 5.0-5.2.1 implementation the Client was required to enter the dotted IP address (example: 209.50.129.50) to locate a Server. Now you can assign meaningful names (e.g: techdb.qsatoolworks.com) to your Servers.

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.

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.
Using the example found above: if you set your Client computer's TCP/IP configuration with qsatoolworks.com as a search domain, you can connect to our tech support database by entering just techdb in Helix's Find Server field.

Assign multiple IP addresses to a Helix Server and Clients will be able to connect to it through any of the addresses.

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 Server can even be run on a Mac with a wireless network connection, but we aren't sure why you'd want to do that.

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: Open port 10860 to allow Helix Clients to initiate contact to the Server.

For more information on firewalls, see this page from techtarget.com.

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.

For an overview of DHCP, see this page from Vicomsoft.
For detailed information on DHCP, visit the dhcp.org website.

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.
For a detailed discussion of NAT, see this page from Vicomsoft.

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.

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.
The Client and Server do not need to have matching PORT resource values for local Clients to log in.
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.

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.
Ideally, you want to assign a host name to the computer and take advantage of DNS resolution so your remote Clients can use a logical name (e.g: techdb.qsatoolworks.com). If you have a static IP address, your ISP should be able to provide you with the DNS name for that address. If you own your own domain, but use dynamic IP addressing, your DNS provider may be able to provide you with Dynamic DNS Resolution.

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.

What is my current public IP Address?

Login passwords are encrypted, but the TCP/IP stream itself (including record data) is sent as unencoded/unencrypted data.
However, to the untrained eye, only text fields will be readable, but they are not seen in a logical context that makes the meaning evident. All other data types are stored (even in the database itself) in an encoded format and they are transmitted in encoded (but not encrypted) form.
If you have a packet sniffer (we recommend Interarchy) you can observe the data flow for yourself. With Interarchy open and set to show all TCP streams, use Helix Client to log in to a Helix Server. You'll see exactly what gets sent over the wires.

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.

Not yet...

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.
For example: if your laptop is plugged into a network cable and you want to switch to Airport, you should disconnect from the Server before making the switch.

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks:

So if your IP Addresses that begin with 10, 172, or 192, you are probably using private IP addressing. Contact your network administrator or ISP to know for certain.
For a detailed discussion of IP Addressing, we recommend this book. A search of the internet for "private IP addressing" will turn up many more references.

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.

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.

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 OS X 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.

Whatis?com is an excellent site that covers these issues in great detail.