Source : Oracle Metalink (support Oracle)
 
 
 
   
 
 
   
 
 
Bookmark
 Go to End
 
 
 
 
Doc ID:  
 Note:125021.1
 
Subject:  
 Oracle Connections and Firewalls
 
Type:  
 BULLETIN
 
Status:  
 PUBLISHED
 
 
 Content Type:  
 TEXT/X-HTML
 
Creation Date:  
 21-NOV-2000
 
Last Revision Date:  
 15-APR-2003
 
 
 
 
 
Oracle Connections and Firewalls
 
 
When the Oracle client makes a connection to the database e.g.
(sqlplus userid/password@alias), it compares the alias name supplied in the
sqlplus line and looks for a match in the TNSNAMES.ORA file or Names server.
Once it obtains the address for the database server, a connection attempt is
made to the server from the client. The Listener is contacted on the database
server and port redirection can take place depending on the platform,
configuration of the INIT<SID>.ORA file and/or the Oracle product being used.
The underlying network layer on the server will obtain a free port from the
Operating System (OS) and send back to the client via the Listener the new port
assignment.  The client will then try to connect to the database on a new port.
This is where connection failure normally occurs.
 
A remote Oracle client making a connection to an Oracle database can fail if
there is a firewall installed between the client and the server and if port
redirection is taking place. The firewall will block the connection to the new
port when the Oracle client connects to the database - the client typically
fails with Oracle errors ORA-12203 or ORA-12535. The client connection failure
is due to port redirection from the Database Server's operating system. Port
redirection requires the client to connect to the database using a different
port than originally configured in the configuration files. Oracle
Multi-Threaded Server (MTS) on Unix platforms, (without specifying the address
with the ports in the INIT<SID>.ORA file), Oracle Secure Sockets Layer (SSL)
and Windows NT/2000 platforms will cause port redirection.
 
A Net8 level 16 client trace file can verify if the problem is a firewall issue.
In the SQLNET.ORA file on the client add the following lines:
 
  trace_level_client  =  16
  trace_file_client = client
  trace_directory_client = a valid directory and path  
 
Save the changes to the SQLNET.ORA file and try connecting with SQL*Plus once to force the error.  This will create a trace file. Here are several excerpts from a level 16-trace file of what to look for.
 
The initial packets sent to the listener on port 1521 in trace file.
 
  niotns: Calling address: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)
  (HOST=server1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=v815.world)
  (CID=(PROGRAM=D:\V815\BIN\SQLPLUSW.EXE)(HOST=server1)(USER=system))))
  nladget: entry
  nladget: exit
  nscall: entry
  nscall: connecting...
  nsc2addr: entry
  nttbnd2addr: entry
  nttbnd2addr: port resolved to 1521
 
The received packet from the listener telling the client to use 1729 port (search for "NSPTRD" ).
 
  nscon: recving a packet
  nsprecv: entry
  nsbal: entry
  nsbgetfl: entry
  nsbgetfl: normal exit
  nsmal: entry
  nsmal: 44 bytes at 0xb892d0
  nsmal: normal exit
  nsbal: normal exit
  nsprecv: reading from transport...
  nttrd: entry
  nttrd: socket 232 had bytes read=64
  nttrd: exit
  nsprecv: 64 bytes from transport
  nsprecv: tlen=64, plen=64, type=5
  nsprecv: packet dump
  nsprecv:00 40 00 00 05 00 00 00  |.@......|
  nsprecv:00 36 28 41 44 44 52 45  |.6(ADDRE|
  nsprecv:53 53 3D 28 50 52 4F 54  |SS=(PROT|
  nsprecv:4F 43 4F 4C 3D 74 63 70  |OCOL=tcp|
  nsprecv:29 28 48 4F 53 54 3D 31  |)(HOST=1|
  nsprecv:33 38 2E 32 2E 32 31 33  |38.2.213|
  nsprecv:2E 36 31 29 28 50 4F 52  |.61)(POR|
  nsprecv:54 3D 31 37 32 39 29 29  |T=1729))|    <- port change
  nsprecv: normal exit
  nscon: got NSPTRD packet  
  nscon: got 54 bytes connect data
  nscon: exit (0)
 
The client resolving the connection to port 1729.
 
  nscall: connecting...
  nsc2addr: entry
  nttbnd2addr: entry
  nttbnd2addr: port resolved to 1729
  nttbnd2addr: using host IP address: 138.2.213.61
  nttbnd2addr: exit
  nsc2addr: normal exit
 
You can see the send packets sent from the client on port 1521 (or your port
if different) to the Listener.  There will be receive packets returned from
the server to the client reflecting a new port assignment.  Then the client
will send packets again from the client only this time to a different port. The
connection will then fail at this point in the trace file.
 
The port that is assigned to the client is randomly chosen by the operating
system and cannot be modified. It can be any free port available (usually above
port 1024) that the server determines is not is use by any other software or
hardware device.
 
Once it is determined that the problem is the firewall causing the connection
to fail, the next step is to select a solution to resolve the issue.
 
As both Oracle and firewall are working correctly, there are several solutions
to correct the problem to allow the clients to connect to the database.
 
 
Solution: Firewall Vendor
 
The first solution is to contact the firewall vendor and see if they have an
upgrade to allow for Oracle connectivity with OS port redirection. If the
firewall software can be upgraded, it is the best solution to follow.
 
 
Solution: Oracle Connection Manager
 
The second solution is available from Oracle Net8 (8.0.x and above), and
requires the configuration of Oracle Connection Manager (CMAN) to allow the
clients to connect through a firewall - Note 2077721.6 discusses CMAN in
detail including configuration examples). CMAN is an executable that allows
clients to connect despite a firewall being in place between the client and
server. CMAN is similar to the Listener i that it reads a CMAN.ORA
configuration file, which contains an address that Oracle Connection Manager
listens for incoming connections, usually default ports of 1610 or 1630. CMAN
starts similar to the Listener and will enter a LISTEN state (see netstat). The
Oracle client must be Net8 or above and have the following in the TNSNAMES.ORA
file.
 
cmantest =
   (description =
     (address_list =
       (address =                 <- first address is to CMAN          
         (protocol=tcp)
         (host=hostname or ip of cman)
         (port=1610)
       )
       (address=                  <- second address is to Listener
         (protocol=tcp)
         (host=hostname or ip of listener)
         (port=1521)
       )
     )
     (connect_data = (sid =  sidname))
     (source_route = yes)         <- This tells the client that it is using
    )                                CMAN and it must take the first two
                                     addresses listed.
 
 
When the client contacts Oracle Connection Manager, CMAN completes the
connection with the second address the client brought with it. The second
address will point to the host machine where the listener is running. CMAN
then uses that address to 'pass' the connection to the Listener and the
connection to the database is established. All redirection takes place between
CMAN and the database, therefore the Oracle Connection Manager installation
should be placed after the firewall but before the database.
 
Several documents exist in MetaLink (http://metalink.oracle.com) that explain
Oracle Connection Manager and provide more detailed configurations. This note
serves to explain the connection process with firewalls, not to go into detail
regarding Oracle Connection Manager.
 
 
Solution: USE_SHARED_SOCKET
 
A third solution for Windows NT/2000 servers is to set USE_SHARED_SOCKET to
TRUE in the Windows registry (see Note 124140.1). This allows the OS to share
the listening port (e.g. 1521) and clients then remain  using that same port
when connecting to the database - no port redirected takes place.  
 
Unix platforms can have problems connecting to a database through firewalls if
they have implemented Multi-Threaded Server (MTS). MTS Dispatchers will
redirect connection ports like the Windows Platforms mentioned above.  
 
 
Solution: Setting MTS ports
 
A workaround for this is to specify the port in the MTS parameters of the
INIT<SID>.ORA file (see Note 1016349.102).  This allows the Dispatcher to
use the port specified and will not select a random port.  Ensure the
user-defined MTS port/s are opened on the firewall.  The following example
shows the ports set to 2450 and 3125.  Set these parameters according to your
individual systems.  This solution will also work for Windows.
 
Example:
 
  mts_dispatchers="(address=(protocol=tcp)(host=hostname)(port=2450))(dispatchers=1)"
  mts_dispatchers="(address=(protocol=tcp)(host=hostname)(port=3125))(dispatchers=1)"
 
Opening ports 2450 and 3125 on the firewall will allow clients to connect to
Oracle.
 
SSL
Using SSL will cause Port redirection. The workaround is to select and set the
ports using MTS in the INIT<SID>.ORA .
 
 
RELATED DOCUMENTS
-----------------
Note 1016349.102 Configuring Oracle MTS with Firewalls
Note 66382.1 Firewalls, Windows NT and Redirections
Note 124140.1 How to configure USE_SHARED_SOCKET on Windows NT/2000
 
.  
 
 
--------------------------------------------------------------------------------
 
 
 
 Copyright © 2005, Oracle. All rights reserved. Legal Notices and Terms of Use.