Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025

 


Article

How to configure the Appserver with a firewall.

« Go Back

Information

 
Article Number000021155
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x
OS: All supported platforms
Question/Problem Description
How to configure the Appserver with a firewall?
How to troubleshoot AppServer connection issues when a firewall is involved?
How do I set up the Appserver with a firewall?
What ports need to be opened between the AppServer and its clients?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
Resolution
First confirm whether the AppServer Internet Adapter (AIA) is being used with the configured AppServer environment.
  • If the AIA is in the picture then the point of failure is between the client (AIA) and the NameServer.
  • If there is no AIA in the configuration and the AppServer is being used, then typically no firewall would be involved. 
    A firewall would usually separate the Internet (thus the AIA adapter enters the configuration) from the network in which the AppServer is running. 
  • If the AIA is not being used and there is a firewall between the client and AppServer, then the AppServer Broker port and all ports between the srvrMinPort and srvrMaxPort values for the Agents (Default: 2002 to 2202) need to be opened.
The following process communications occur during the communication process between the NameServer and the Messenger/AIA/brokers:
  • The NameServer listens on a UDP port (Default: 5162). 
  • UDP is a one-way broadcast. When a Messenger/AIA/Broker sends a message to the NameServer it does so to the port number of the NameServer; there is no open connection between the two processes.
  • In order for the Messenger/AIA/Broker to receive a response back from the NameServer, it needs to listen on its own UDP port number. 
  • The UDP port number is arbitrarily assigned by the Operating System and it is this UDP port number the NameServer uses to respond. 
When the AppServer or WebSpeed Broker and the NameServer exist on the same side of the firewall
there should be no problem using random Port Numbers when communicating between these two - the Operating System always assigns a free UDP port number. 
 
When the NameServer has to communicate with the AIA or WebSpeed Messenger, these processes usually sit on the other side of the firewall.  
  • The NameServer listens on only one port number, which needs the firewall to be configured for that one UDP port number open for incoming traffic.  
  • The firewall also needs all of its outgoing UDP ports opened in order for the NameServer to successfully communicate back with the AIA/Messenger (the whole range of ports is 1024 to 65535) .
To help reduce the number of UDP ports required to be open for outgoing requests:
  • Progress 9.1B introduced the minNSClientPort and maxNSClientPort configurable options for Messenger and AIA instances. 
  • This range of UDP ports need to be configured on the firewall opened for outgoing traffic
  • Then configure the appropriate WebSpeed Messenger/AIA adapter instance and set the range accordingly in the ubroker.properties. 
  • It is not possible to limit the range to a single port number.
Example: The cgiip messenger creates a new process for every client request coming in.  
There could be hundreds of these requests running simultaneously, but that does not mean that many open UDP ports are required, because most of the connection time occurs via TCP between client and WebSpeed Agent/AppServer.
To find the right number of ports to open for each specific configuration may require trial and error or network tracing tools such as WireShark.
 
How to diagnose communication issues:
 
1.  Test the basic AppServer infrastructure

Ignore the internet for a moment - first ensure that everything is up and running. If the following three tests all pass, the basic AppServer infrastructure is sound and the Firewall and AIA can be configured.
  • Query the AppServer broker with ASBMAN to ensure that it reports at least one AppServer is available .
  • Query the NameServer with NSMAN to ensure that it has registered the AppServer. 
  • Start an ABL client session (within the firewall) that connects through the AppServer, then execute a query that executes with a client server connection.
Example:
DEFINE VARIABLE iCount AS INTEGER NO-UNDO.

DO iCount = 1 TO 2:
    RUN conn.
END.

PROCEDURE conn.
    DEFINE VARIABLE hAppServer AS HANDLE NO-UNDO. 
    CREATE SERVER hAppServer.
    hAppServer:CONNECT("-AppService asbroker1 -H <hostname> -S 5162").
    IF hAppServer:CONNECTED()
        THEN DO:
        hAppServer:DISCONNECT().
    END.

ELSE MESSAGE "Not connected!" VIEW-AS ALERT-BOX.

    DELETE OBJECT hAppServer.

END PROCEDURE.
 
2.  Examine the Firewall and AIA configuration.
 
  • Test the connection to the AIA: Is it possible to get the AIA OK screen in a Browser to verify that the AIA servlet was queried? 
http://host-name/servlet/Aia
http://localhost:8080/aia/Aia
 
Go through all of the checks to ensure that the Java Servlet Engine (JSE) is up and running and that the AIA instance is configured correctly.

3.  Once basic AppServer and AIA communication are working, examine the firewall configuration in greater detail:
  • Is the UDP port number of the NameServer open for incoming traffic?
  • Are outgoing UDP ports open?  
    If they are closed, then the NameServer cannot send a response back to the client. 
    ​Use the minNSClientPort, maxNSClientPortrange described above to limit the number of outgoing UDP ports on the firewall.
  • If Network Address Translation (NAT) is being used, examine the translation table.  Refer to the appropriate vendor documentation to determine how to do this or engage a Network Administrator. Even when not using an actual NAT, there may be a firewall that provides the same type of capabilities. Determine the real IP address the host of the AppServer Broker is running on and match it to what the NAT expects to get from the outside world.  
  • Take the external IP address and in the ubroker.properties file add to the instance of the AppServer broker: 
    • registrationMode=<OutSide IP Address>
  • Alternatively, there are far too many ways for the OS to return host name/IP address that the various clients involved will not translate appropriately. The network topology ( ipv4, ipv6, bind, dns settings etc. ) can often cause unexpected results, especially then the client is behind NATed router/firewall. Consider configuring the following in the broker's section:
    • registrationMode=Register-HostName
    • hostName=<enter-host-name>
In this way the hostname will be exactly what is returned by the NameServer.  Then focus on ensuring that client side of the communication knows how to resolve that hostname to the proper address. Stop the broker and restart it to make sure that new ubroker parameters are picked up. 
 
  • ​Run a NSMAN query on the NameServer to verify that the AppServer Broker has registered with the NameServer and that the hostname/IP address is listed. Authenticate to ensure that it picked up the expected values.
Workaround
Notes
Attachment 
Last Modified Date11/6/2019 10:26 PM