I recently enabled SuSEfirewall2 on several servers (SLES 10 SP4 on System z) that host DB2 9.5 and closed almost all of the ports. One of the Prod DB2 servers needs to export its DB2 /logs and /backup directories (5 file systems) to one of the Test DB2 servers. This is to save the time it takes to ftp the data to the test server if/when a DB2 recovery is needed (we recover the data to the test server, then the user extracts the needed data and imports it back into the production DB2).
When the firewall rules were enabled on Prod DB2, we found that issuing a ‘mount’ or ‘df’ command on the Test DB2 server would lock up the PuTTY session. I determined that ports 111 and 2049 needed to be opened on the Prod DB2 server to allow the test server to access the file systems. After the rules were modified SuSEfirewall2 was restarted the ‘mount’ and ‘df’ commands would still lock up the PuTTY session. Browsing the firewall log at /var/log/firewall showed the the test server was trying to access port 745. Opening port 745 resolved the problem.
I need to determine, for my PCI documentation, why port 745 needs to be opened. I Googled ‘port 745’ and all of the pages I looked at said that this is an unassigned port. I tried to track it down on Test DB2 with ‘netstat -a’ but nothing shows up.
What is also disconcerting is that I have several SLES 11 SP2 servers (also System z) running with SuSEfirewall2 enabled that are nfs servers. Port 745 is not open on these servers and all of the nfs clients are able to access the exported fie systems.
Does anyone know what service on the client server is using port 745?
Does anyone know why port 745 doesn’t need to be opened on a SLES 11 system but does on a SLES 10 system?
Harley