How Infrastructure Management interfaces interact with firewalls
Firewalls block a wide range of TCP ports required by one or more Infrastructure Management components. Usually, this only affects the TrueSight Infrastructure Management administration console because it requires a wide range of TCP ports for efficient operation.
Managing TCP IP port restrictions
Port restrictions affect the administration console because it uses a JAVA communications protocol called RMI (Remote Method Invocation). The Administration Console connects to Infrastructure Management Server using one of the following methods:
- The client first tries to contact the server on TCP port 1099. If the connection is successful, the client and server randomly negotiate a free port between 10000 and 65000, and then reconnect on that port (the connection on port 1099 is closed). This direct connection is the most efficient form of RMI communication. If a wide range of ports is not available, this first connection method cannot be used.
If the first method fails, the client builds a URL to the server's host and port and uses an HTTP POST request on that URL, sending the information to the server's method skeleton as the body of the POST. This method is slower than the direct TCP connection because the HTTP encapsulation adds overhead to the client's RMI requests.
To activate the Apache proxy on the Infrastructure Management Server, see Activating the Apache proxy server.
- If the second method also fails, the client builds URLs to the server's HTTP port, using a CGI script that forwards the posted RMI request to the server. This is the slowest technique because the CGI wrapper adds considerable overhead in addition to the HTTP encapsulation.
Methods 2 and 3 are noticeably slower than the direct TCP method of remote invocation. If the Administration Console operations seem sluggish, the first test you must try is to attempt a direct connection on port 1099 by running the following command:
Under special circumstances, it is possible to avoid the sluggishness of methods 2 and 3. This workaround, if permissible, requires you to launch the pw admin command from the server and direct the xwindow output across the firewall to the user's computer. This can be accomplished by setting the DISPLAY variable to point to the IP address of the user's console ("setenv DISPLAY 123.45.67.89:0.0") and punching holes through the firewall for TCP ports 6000-6004 and UDP ports 177 and 32798.
Activating the Apache proxy server
When the proxy feature of Apache Web server is activated, it enables the administrator client to form a virtual RMI connection with Infrastructure Management Server using HTTP POSTs and GETs for RMI. For security, the proxy is deactivated in the default configuration of Infrastructure Management Server.
To activate Apache proxy server
- Access the appropriate directory for your operating system:
- (Windows)installationDirectory\pw\apache\extra
- (Linux)/usr/pw/apache/extra
- Open the httpd-proxy.conf file in a text editor.
- Locate the following group of lines:
# Proxy Server directives. Uncomment the following lines to |
For minimum security risk, specify a list of specific host and/or network addresses in this allowed hosts section. For example,
Order deny, |
If a firewall uses NAT (Network Address Translation) whose translation is one-to-one, it causes problems for the Administration Console. To overcome this, certain configuration changes must be made on the server.
If Infrastructure Management Server is behind a firewall and the NAT translation is many-to-one (for example, the firewall uses IP masquerading), then the Infrastructure Management Server is inaccessible to the Administration Console.
For information about using Infrastructure Management through a NAT-enabled firewall, see Configuring for use with a NAT firewall.
Configuring for use with a NAT firewall
When Infrastructure Management Server and a user are on opposite sides of a NAT-enabled firewall, it can create difficulties when trying to access the server with the Administration Console. These difficulties can be overcome by making two configuration changes.
You must modify the following two files on the Infrastructure Management Server when dealing with a NAT-enabled firewall (Ensure that you make a backup of each file before modifying):
- (Linux) In /usr/pw/apache/conf/httpd.conf or (Windows) in \pw\ApacheGroup\Apache\conf , modify the ServerName entry to use the host name of the Proactive system rather than the private IP address (note that there are two of these entries). By default, this entry uses the private IP address of Infrastructure Management Server.
(Linux) In /usr/pw/pronto/conf/pronet.conf or (Windows)\pw\ApacheGroup\Apache\conf, modify the pronet.rmi.server.hostname entry to use the host name of Infrastructure Management Server. By default, this value is not assigned and defaults to the private IP address of Infrastructure Management Server (to make this change permanent and to ensure that the change is preserved during upgrade, copy the entire line to /usr/pw/custom/conf/pronet.conf).
The host name must resolve to the proper address on both sides of the firewall. If DNS service cannot resolve the name, then an entry must be made in the hosts file of Infrastructure Management Server and every computer that runs the administrator client. On Microsoft Windows, the hosts file is located in \WINNT\SYSTEM32\drivers\etc\hosts.
After making these changes, restart the Infrastructure Management Server using the pw system start command.
Related topic