1. HFS configuration details
The HFS can be accessed from behind a firewall. Although all client sessions, even automatic scheduled backup sessions, are initiated from the client, it is necessary to place a rule in the firewall to allow traffic both to and from the TSM server in order to allow the TSM server to communicate with the TSM client. The current IP addresses/port number combinations for the service are:
|Server Name||DNS Name||IP Address||Port||HFS Service|
|OX_HFS_B6||dsmb6.ox.ac.uk||188.8.131.52||2700||Large server backup|
|OX_HFS_B12||dsmb12.ox.ac.uk||184.108.40.206||3300||Large server backup|
|OX_HFS_VPN||dsmvpn.ox.ac.uk||220.127.116.11||3200||Desktop VPN-based backup|
|OX_HFS_DD1||dsmbdd1.hfs.ox.ac.uk||18.104.22.168||3400||TSM for VE server backup|
2. Trouble-shooting firewall-related issues
A number of HFS users have had problems when connecting to the HFS through a firewall. These problems are characterised by backups/restores stalling half-way through and by repeated reconnections being made though a long scheduled backup. This is normally seen in the client logs as a large number of messages of ANS1809W messages, which take one of the following forms:
ANS1809W Session is lost; initializing session reopen procedure.
ANS1809W A session with the TSM server has been disconnected. An attempt will be made to reestablish the connection.
It appears that these problems usually arise with firewalls based upon Linux 2.6 kernels. The workaround successfully used by a number of HFS users is to set the value
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
This setting means that any packets interpreted by the firewall's connection tracking as being outside the TCP window will still be allowed through, unless they are reset segments.
We have also seen similar issues with commercial firewalls not based on Linux, where turning off
flow consistency checking has alleviated this problem.
If you experience slow or intermittently slow backup or restore performance rather than a loss of connection, then the cause could nonetheless still be firewall-related. Please check any intervening firewalls for active anti-virus/anti-malware scanning. Packet-scanning in transit can seriously affect data rates, even on otherwise uncongested network links.
Some departments have reported problems related to deep packet inspection (DPI) firewalls and access to the archive service (please note this does not affect the backup service). The HFS archive service uses TCP port 2000, and this port is also used by SCCP (Cisco's Skinny Client Control Protocol). DPI firewalls with support for SCCP expect only to see SCCP connections using port 2000 - they view the TSM connection to the HFS archive service as erroneous and terminate it. On the client machine this is normally seen as a hang while starting the TSM software for archiving. To fix this problem, DPI must be disabled for SCCP/port 2000 on the firewall. On Juniper firewalls, the Application Layer Gateway settings need to be changed. For example, on the Juniper SSG140, issue the following command in the firewall command line interface:
unset alg sccp enable
The equivalent command on the Juniper SRX650 is:
set security alg sccp disable