Troubleshooting Firewall-Secure Communications

Troubleshooting a network communications interface which includes the ACSLS platform and clients, and now includes intervening firewall(s), may involve multiple steps. By introducing the firewall(s) into the path between ACSLS and its clients, there are more potential causes for network communications failures. Additionally, there are more components that must be configured in a way that corresponds with the settings in other components, and if these settings do not match, the network communications will be impacted. Here is a list of things to check and try if you have done all the configuration work on ACSLS, its client(s), the firewall(s), and network communications are not working.

1. Checking the ACSLS platform:

   • Is the ACSLS up and running? If not, check the acsss_event.log for possible reasons, or for pointers to a possible culprit.

   • Is the CSI being brought up successfully by ACSLS? If not, there should be informative messages in the acsss_event.log which point towards the cause. Bad values for some configuration parameters or a port conflict are likely possible causes.

   • Is there a port conflict being reported in the acsss_event.log which causes the CSI to fail? If so, you should use the “netstat" or similar system utility to tell you which ports are in use on the system, and configure the ACSLS to use an available port. Remember to reconfigure the firewall to match.

   • Is the CSI registering for the port you expect? Use the command 'rpcinfo -p' to look at the portmap table. The CSI is registered under program number 300031. Check to make sure that the port registered under that program number is the one you expect (the default port is 30031, with one less zero than the program number).

2. If ACSLS and the CSI are up and running and are correctly registered, the next step would be to check access to the ACSLS platform across the firewall:

   • Is the ACSLS reachable through basic RPC? Use the “rpcinfo -t <hostname> <program-number> <version-number>" command to send a simple RPC request to the CSI. (Use “man rpcinfo" on your system to get more information on the rpcinfo command and its use.) Do this from a machine on the inside of the firewall with ACSLS (such as, from the ACSLS platform itself), and from outside the firewall. If it works from inside but not from outside, then the firewall is intercepting your ACSLS requests. Double-check the configuration of the firewall and the ACSLS port. Check to be sure that the portmapper is accessible through the firewall (this test cannot be used from outside the firewall if access to the portmapper is disallowed).

   • Do the ports configured for ACSLS and for the firewall, match? Double-check these parameters. This is a likely cause of failure in network communications. Aside from the configured values, perform the 'rpcinfo -p' command mentioned above, to insure that the CSI is indeed registering with the expected portnumber. If it is not, look in the acsss_event.log for information about the cause.

   • Is the ACSLS receiving requests, but unable to send back responses? If you check the acsss_event.log and find that the CSI reports many dropped network packets or failures to communicate with network clients, then the client requests are getting in, but the responses are not getting out. Again, this is an indication that they are being blocked by a firewall.

3. If your problems are still not resolved.

   The above addresses several levels of things to look for. If these yield no specific answer, it is time to do some lower-level checking to find out where communications are being broken-down. The best way is through the use of a network packet sniffer facility, such as 'snoop' under Solaris. Use “man snoop" on your Solaris-based system to get more information on the snoop command and its use.

   Similar packet tracing facilities are available on other network-connected systems.

   • To use this, you have to do your packet sniffing from locations that show you where the packets are getting to, and where they are being lost. This may be from both inside and outside of the firewall.

   • Additionally, looking at the packet data will be informative. If either side is allowing use of the portmapper, it is likely that you will see some PORTMAP packets.

   • Also, you should see RPC packets passing between the ACSLS and its clients.

   • Finally, looking at the transport-level TCP connection will inform you of the specific ports being used on each side for the connection. This is often critical information to find out where the communications are being stopped.

More detail on performing these operations is beyond the scope of this manual, but your System Administrator should be able to provide some help in this area.