View source for Using Supportworks through a Firewall or over VPN/NAT

{{Template:Basic Cover
|title=Using Supportworks through a Firewall or over VPN/NAT
|type=FAQ
|htl=Y
}}

{{Template:Basic Status
|status=Published
|version=1.5
|authors=HTL QA
|applicableto=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 ===

{{Supportworks Services and their Ports}}

=== 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.