Kbase P3259: What ports need to be opened to connect to an AdminServer or Progress Explorer behind firewall ?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/02/2011 |
|
Status: Verified
GOAL:
What are Additional Ports that Need to be Opened for AdminServer to Go Through A Firewall.
GOAL:
What additional ports need to open between admin server and progress explorer?
GOAL:
Which ports needs to be open on a Firewall between Progress Explorer and AdminServer?
FACT(s) (Environment):
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
CAUSE:
In the past, we have seen many customers trying to connect Progress Explorer to the AdminServer behind a firewall, opening only the port that AdminServer is running on, this will cause Progress explorer not being able to connect to AdminServer.
By default, AdminServer runs on port 20931, but this is not the only port that the AdminServer and Progress explorer need to communicate with each other.
Progress Explorer and the AdminServer are both Java processes that communicate with each other using Remote Method Invocation (RMI) interface. RMI works on a very similar principle to the Remote Procedure Call (RPC) protocol. The idea in both protocols is that servers shouldn't need to operate on well-defined service ports (these are limited in number, and require global registration), they can listen on any available port and a registry will translate between a service and its listening port. In the case of RMI the registry is rmiregistry. The only port which needs to be determined in advance is the port on which the registry listens this is port 20931 for the AdminServer.
An RMI server must register itself with rmiregisty and tell the registry which port it is listening on. When a client wants to use a service it doesn't initially know where that service is available (the servers listening port). So it asks the registry for a particular service, and the registry will tell it what port that service is available on. The client then contacts the service directly on its listening port.
So, the RMI registry is listening on port 20931 and your RMI server is listening on a randomly-attributed port. The Progress Explorer then contacts the server on its randomly-attributed listening port. Your RMI client (Progress Explorer) contacts the RMI registry on port 20931 and asks where the service it wants can be contacted and is told that it is available on a randomly-attributed port.
The client then contacts the server on this dynamically-attributed port. There will be 2 established connections from the client to the server, to port 20931 for the rmiregistry and to the dynamic port to the RMI server itself.
The problem comes from the fact that the use of NAT or firewall prevents the client to access the server port, attributed on a random fashion.
In the code, a UnicastRemoteObject is being instantiated using following constructor without a port specification:
"protected UnicastRemoteObject() throws
RemoteException Create and export a new UnicastRemoteObject object using an anonymous port."
FIX:
1. AdminServer and Progress Explorer are never intended to use going through firewalls. Currently the way code is written, there is no control over which ports need to be open, thus the firewall needs to have all the ports open.
2. If security is at stake, the only solution would consist in setting a VPN connection between the client and the server, bypassing in that way the NAT port filtering rules. You might for instance deploy a second NIC card on the client that will be use solely to establish the VPN tunneling between the Progress Explorer and the AdminServer.
3. Use the new OpenEdge Explorer which has replaced the Progress Explorer Tool and only requires one port to be open.