Using Supportworks through a Firewall or over VPN/NAT

Status:	Published
Version:	1.5
Authors:	HTL QA
Applies to:	All Supportworks ESP versions

Using Supportworks through a Firewall or over VPN/NAT

Introduction

This topic starts out by indicating what ports are in use for each of the Supportworks services and then goes on to provide some useful background information that should be of help in the task of configuring a firewall to allow Supportworks Version 6.x and 7.x to operate through it. You need to understand the information set out here when your Supportworks server is located on one side of a firewall and there are some client instances running on the other side, or when client/server communication is across a VPN or NAT'ed network infrastructure.

You will need to understand TCP/IP networking to make real sense of this document. The person responsible for your company's network infrastructure, and who will be tasked with ensuring that the Supportworks application runs in your environment, should read and understand this document.

Supportworks Services and Ports

There are various services that Supportworks loads and runs. Each service is provided as a TCP protocol connection from the Supportworks server on specific ports - which you have to ensure your firewall keeps open. The following table shows the services provided, the name of the module that provides each one, the port that each service is provided on and the versions of Supportworks to which those ports apply:

Service	Module Name	Port	Versions
Supportworks services via binary requests	SwServerService	5001 (Default)	All
Supportworks SQL server	SwSqlServer	5002 (Default)	Up to 7.5
KnowledgeBase index server	SwIndexServer	5003 (Default)	Up to 7.4.1
Supportworks mail services	SwMailService	5004	Up to 7.4.1
Supportworks services via text-based requests	SwServerService	5005	All
Supportworks Messenger services	SwMessengerService	5006	All
Supportworks calendar services	SwCalendarService	5008	Up to 7.4.1
Supportworks calendar services over XMLMC	SwCalendarService	5013	From 7.4.0
Supportworks mail services over XMLMC	SwMailService	5014	From 7.4.0
Supportworks services over XMLMC	SwServerService	5015	From 7.4.0
Supportworks FTP services (My Library)	SwFileService	21/5021 (Default)	Up to 7.4.1
Supportworks HTTP services with HTTP configured	SwHttpServer	80 (Default)	All
Supportworks HTTP services with HTTPS configured	SwHttpServer	443 (Default)	All

For firewall configuration purposes, you can ignore any services/ports that do not apply to your particular Supportworks version.

Any port shown above as the default for a given set of Supportworks services is changeable, which means that an alternative port may have been chosen by your organisation if they wanted to use the original for something else. Such a change, however, will have been highly unlikely - except to HTTP port 80, which is commonly used by Web servers in general.

Note that the default port for Supportworks FTP services changed from 21 to 5021 in Version 7.4.0.

Server-to-Client Notifications

The Supportworks server notifies a client that an item has changed (part of Hornbill's NPA specification) by sending the client one or more messages. This saves the client from having to poll the server to determine if anything being displayed has changed. The notification protocol used on the current version of Supportworks ESP is TCP. When you configure a firewall, it is important to understand how TCP notifications work. The process is in three stages:

Stage 1

The client connects to the server via TCP on port 5001. This is the main session connection and remains open for the duration of the client session.

Stage 2

The client connects a second time to the server via TCP on port 5001. The server "holds" this connection open and associates it with the session created in Stage 1. The client waits on this socket indefinitely (for as long as the main session connection is established) for messages from the server.

Stage 3

When the server wishes to send the client a notification, it will use the second socket to send the NPA data down that already established TCP connection.

Configuring the Firewall

A firewall is simply a router that allows the network administrator to control the way in which TCP/IP traffic is routed. When configuring a firewall to allow unhindered communication between the Supportworks server and its remote clients, you may need to set up a number of services/rules on the firewall. Supportworks needs these rules to operate correctly in such circumstances.

The exact way in which these rules should be applied to your firewall very much depends on both the particular firewall in use and the way in which it and your network are configured. Nevertheless, we have at least been able to indicate the basic pseudo-rules that you would generally need to apply to your firewall. These are given in the Pre-installation Requirements section of the Supportworks Server Installation Guide.

Can I Run Any Kind of Firewall on the Supportworks Server Itself?

Basically, the answer is "Yes", but only if the firewall is properly configured. If not, it will most likely cause problems. The Supportworks server is made up of a number of NT services, as well as detached executable processes. They generally talk to each other using TCP even though they are on the same computer. If you have any firewall software that interferes with this communication, it will create all manner of problems. Supportworks is an enterprise application; give it a server to run on and secure the larger network - we recommend that you do not try to secure the local computer's network.

If you really do need to run a firewall on the server, you will have to set up the same Supportworks-required rules on that as on your organisation's firewall.

What About Client-Side Firewalls?

If a client machine is running Windows XP or later, the firewall that comes with those operating systems can cause issues with Supportworks. Even when the firewall is disabled, it would still be running some basic stubs that could interfere with client/server operation. For that reason, we have indicated what Windows network-configuration commands need to be executed on the client machine to set the necessary exceptions. These are given in the Pre-installation Requirements section of the Supportworks Client Installation Guide.

Appendix: The UDP Notification Option on Older Systems

On versions of Supportworks ESP up to 7.4.1, the server-to-client notification protocol (as configured in the Communications tab of the version of the Server Configuration utility that came with those systems) could optionally be set to UDP instead of TCP. The way the UDP notification process works differs from the way it works with TCP. The relevant stages in this case are as follows:

Stage 1

On the client computer, when the client first runs, a local client socket is created to listen for updates from the server. It binds to a port, on the client computer, allocated by the operating system. Typically, this port is within the range 1024 to 65535.

Stage 2

The client connects to the server via TCP on port 5001. This is the main session connection and remains open for the duration of the client session. When the client logs into the server, the client tells the server what UDP port number it has bound to for notifications. The server records both the client's IP address and this port number against the session that has been established.

Stage 3

When the server wishes to send the client a notification, it would use the IP address that the client has connected from and the port number sent in Stage 2 above, and will send UDP packets. It is important to note that the server always sends these UDP messages from its own port 5001, to be delivered on the client's dynamic port number as provided above.

Why Was there a Choice of Two Protocols?

As each protocol resolves different problems, we previously provided a choice of two to allow you to optimise Supportworks in your environment. Even today, Windows OS's and current hardware platforms run out of steam before the Supportworks architecture does. For notifications, Supportworks was historically configured to use UDP by default. UDP mode is known in TCP/IP terms as an unreliable protocol. That's not to say it's unreliable in real terms, but merely that TCP/IP itself does not guarantee that a UDP packet will reach its destination.

Depending on the physical transport, UDP may have been a better choice than TCP for performance and bandwidth. When you send data over Ethernet using UDP and your data is less than about 1500 bytes, each transmission directly converts to a single Ethernet packet. This could well become 3 to 5 packets over TCP. With today's modern hardware, using UDP on an averagely loaded switched Ethernet network is pretty much 100% reliable. So if your pre-7.5.0 Supportworks deployment is on a switched LAN with average load, UDP will give you not only the best performance but will reduce the noise on the network too - we like Supportworks to be unobtrusive.

Unfortunately, UDP notification is difficult (but not impossible) to configure on a firewall. It requires that the security model works in reverse, at least conceptually, and that worries some people. However, if you have an in-depth understanding of firewall technologies, you will know that it is entirely possible to configure UDP securely. In fact, reliability of UDP becomes a bigger concern. If you are using Supportworks on networks that are routed, have firewalls between end points, are heavily loaded and shared with many applications, have high latency, are VPNs or any other non-physical transports, or if you are running your server on any kind of virtualisation software such as VMware, then you would, in most cases, have no choice but to use TCP instead. In these environments, you need the guarantee that TCP provides in terms of message delivery, although you will suffer a slight performance overhead, along with additional network traffic and also a resource overhead on the server (because it now needs two TCP sockets per session instead of one). TCP is more firewall/VPN-friendly since all connections between the client and the server use TCP and are initiated from the client. Firewalls generally allow you to easily configure TCP proxy services that understand the concept of client-initiated connections. Therefore, from Version 7.4.0 onwards, Supportworks was configured by default to use TCP notifications and, from Version 7.5.0 onwards, the option to use UDP was removed altogether.

The original implementation of Supportworks Non-Polling Architecture used UDP for server-to-client notifications and therefore relied on direct TCP/IP communication from the server to the clients, which was not very easy to configure for firewalls and NAT setups. To address this, Supportworks Version 6 implemented TCP notifications that use client-initiated long-polling TCP/IP connections requiring no special network configuration to work.