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:

  1. 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. 
  2. 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.

    Note

    This method requires that Apache proxy is activated on Infrastructure Management Server.

    To activate the Apache proxy on the Infrastructure Management Server, see Activating the Apache proxy server.

  3. 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:

telnet Infrastructure Management Server.mycompany.com  1099


Warning

The following workaround involves some security risk and might not always work. For more information, see Sunsolve Infodoc 18370.

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

  1. Access the appropriate directory for your operating system:
    • (Windows)installationDirectory\pw\apache\extra
    • (Linux)/usr/pw/apache/extra
  2. Open the httpd-proxy.conf file in a text editor.
  3. Locate the following group of lines:

 

# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
#
# ProxyRequests On
#
#
#    Order deny,allow
#    Deny from all
#    Allow from .your_domain.com
#    Allow from all
#
#
and uncomment the line "ProxyRequests On" and one or more of the appropriate access
rules. For Example: "Allow from all" or "Allow from  .your_domain.com" where you
substitute the actual domain name of your network.
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
 ProxyRequests On
#
#    Order deny,allow
#    Deny from all
#    Allow from .your_domain.com
    Allow from all
#

Unless Infrastructure Management Server is protected by a firewall, do not comment out the Allow from all line (the last line in the above example). This can make Infrastructure Management Server and your internal network vulnerable to attack from outside.

For minimum security risk, specify a list of specific host and/or network addresses in this allowed hosts section. For example,

 

Order deny,
allow Deny from all Allow from 192.16.26.0/24  #specify network address as (network
addr.)/(subnet mask) Allow from 192.16.27.0/24 Allow from 192.16.31.0/24
Allow from 172.17.52.150     # specify host address as 4 octets
Allow from 172.17.52.151
Allow from 172.17.52.148
Deny from all
Allow from 192.16.26.0/24  #specify network address as (network
addr.)/(subnet mask) Allow from 192.16.27.0/24 Allow from 192.16.31.0/24
Allow from 172.17.52.150     # specify host address as 4 octets
Allow from 172.17.52.151
Allow from 172.17.52.148

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

    Note

    Ensure that you do not insert any extra spaces or tabs within the line or at the end of line as it can cause problems. 

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

Troubleshooting the deployment of packages

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*