Connecting a standalone Java client remotely across a firewall using Network Address Translation (NAT) to an EJB running on the WebSphere Application Server.

Technote (FAQ)
Problem
This technote describes how to connect a standalone Java client remotely across a firewall that has Network Address Translation (NAT) enabled to an EJB running on the WebSphere Application Server. It is assumed that RMI/IIOP is used as the communication protocol.

Environment:
WebSphere Application Server 3.x Advanced Edition, 4.0.x AE & AEs
Firewall with Network Address Translation (NAT) enabled
Cause
When a firewall using NAT is placed in between a stand alone Java client using RMI/IIOP and the WebSphere Application Server box, which contains the corresponding EJB that is communicated with, the communication fails.

This is because the IOR packets contain the IP address of the WebSphere Application Server box in the body of the packet, which NAT doesn't translate. NAT only translates IP addresses in the packet header. As a result, the standalone Java client's JNDI interface tries to resolve the IP address of the WebSphere Application Server box as it is known on the other side of the firewall, rather than the translated IP address.

Solution
To solve this problem, we need to replace the IP address embedded in the IOR packets with a hostname of the WebSphere Application Server box. Specifically, the shortname of the hostname. Having this same shortname be resolved to the translated IP addresses of the WebSphere Application Server box will allow the stand alone Java client to communicate with the application server. Here are the instructions:
  1. First follow the instructions in the DCF technote 1008407 titled "Ports required for EJB Client through a firewall" to open the needed ports through the firewall.
  2. On the WebSphere Application Server box, make sure the shortname of the box resolves to the IP address of the WebSphere Application Server box. This can be done either through the DNS server, or through the hosts file on the WebSphere Application Server box.
  3. On the box running the stand alone Java client on the other side of the firewall, make sure the same shortname of the WebSphere Application Server box resolves to the translated IP address of the WebSphere Application Server box. This can be done either through the DNS server, or through the hosts file on the box running the stand alone Java client.
  4. Make sure that the firewall also translates the address of the box running the stand alone Java client so that the WebSphere Application Server box can see it.
  5. Stop WebSphere Application Server, and add the following line to the <WAS root>/bin/admin.config file. The shortname may be case sensitive depending on the method of name resolution:
    com.ibm.CORBA.LocalHost=<shortname>

    1. Using the admin console on the same side of the firewall as the WebSphere Application Server box, add the following parameter to the Command Line Arguments property field of the appropriate application server(s). The shortname may be case sensitive depending on the method of name resolution:

    -Dcom.ibm.CORBA.LocalHost=<shortname>

    2. Start the WebSphere Application Server and try to connect from the box running the standalone Java client:
    java -Dcom.ibm.CORBA.BootstrapHost=<nodename of WAS server>-Dcom.ibm.CORBA.ListenerPort=<listener port # on local box>


NOTE: If using WebSphere Application Server 3.5.3 to 4.0.2, interm fix PQ56074 is required.











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, Security
Operating system(s): Multi-Platform
Software version: 3.0.2, 3.0.2.1, 3.0.2.2, 3.0.2.3, 3.0.2.4, 3.5, 4.0
Software edition: Advanced
Reference #: 1006502
IBM Group: Software Group
Modified date: 2004-08-14