3 Replies Latest reply on Oct 1, 2004 2:56 PM by rlokuge

    adapter behind a firewall

      I would like to locate a DB adapter on a production site.

      I identifies 2 type of connections for the AGENT part :
      - JDBC Thin (4 Oracle connections per agent with no partition)
      - GIOP to Java repository process ( 2 connexions , one on port 60580, and on on port 60578)

      I have no problem with JDBC thin as my Hub machine is on a Unix machine and so port filtering is sufficiert.

      My question is more on GIOP :
      Are these 2 ports fixed or is there other rules ?

      Thanks for your help,

        • 1. Re: adapter behind a firewall
          In fact the 2 GIOP port are not fixed and this is a problem
          Is there a solution ?
          • 2. Re: adapter behind a firewall
            It is possible to fix the CORBA port in the repositori.ini file since the patchset #2 (and > one off-patch 2767871 on top of it)

            Opened port are : n and n+1

            Thanks to the Oracle Support team
            • 3. Re: adapter behind a firewall
              Here is the contents of an email from Oracle, we had similar proble,s with firewalls. Hope this useful.



              Hi Romesh,
              as discussed, here's a brief explanation of how this works:
              when the patch I mentioned above is NOT installed, when the repository is started it opens a random port to be used for future CORBA connections to it by other components, such as iStudio and the adapters. The fact that this port is random, is related to the way CORBA works. The repository process then writes this port number to a database table, for reference. When an adapter is started, it first makes a connection via SQL*Net to the database and, amongst other things, retrieves the port number, which the repository is listening on. This is why you are seeing one successful connection to the database. After having retrieved the CORBA port number, the adapter process then attempts to open TWO CORBA connections to the repository using the port number adverrtised in the database table and that port number + 1. (The second one is always the first one +1 and is used, I believe, for the return connection by the repository process).
              This scenario works fine in non-firewall installations, as all ports are open.

              When there is a firewall between the repository and adapters, then all these (three) ports need to be opened in the firewall. This is simple for the SQL*Net port, as it is known (usually 1521) but problematic for the CORBA ports, as they are allocated randomly. For this reason, Oracle released the patch 2767871 (and following incremental patches which include it too), which allows you to specify the port which the repository will use for the CORBA connection. So, if for example, you specify port 10000 in the repository.ini, it will accept CORBA connections on port 10000 AND 10001. So you will need to open ports 1521 (or whichever port the SQL*Net listener is configured for), port 10000 and 100001 in the firewall.

              If there are more than one firewall or routers between the repository and adapters and/or iStudio, then the network administrators need to take this into consideration, i.e. that the repository will be expecting connections on these and only these ports, and the adapters and/or iStudio will be attemping to connect to the repository via them too. If the firewalls or routers inbetween are modifying the ports, then this won't work.

              Also, please note that if you are using NAT (Network Address Translation) routers or software, this will probably not work at all. NAT routers change, for example, the IP address of a node to make it appear to be reachable via a different IP address to other systems outside the sub net. However, as the information advertised by the repository process regarding it's CORBA connection contains not only the port number, but also the IP address, adapter and istudio processes will not be able to connect, as the NAT router will make the repository's machine available to them under a different IP address to the one they are attemping to connect on.