Note:131524.1 Firewalls on Windows and UNIX - For Oracle versions 7.x, 8.0.

x,
8.1.x

PURPOSE
-------
To explain, how Sql*Net 2.x/Net8 works and can be configured to work through
a firewall.

SCOPE & APPLICATION

-------------------
Oracle database 7.x, 8.0.x and 8.1.x for Unix and Windows.

I / Oracle7 (7.x) - Unix: Firewall without Network Address Translator (NAT)

--------------------------------------------------------------------------
1 - In dedicated server mode, Unix natively implements TCP/IP sharing, so
there should be no problem with connectivity.
2 - For Multi-Threaded Server (MTS) mode, there is no solution other than
to use a sqlnet proxy such as a firewall.

OR

configure MTS to use specific TCP/IP ports through which connectivity

may occur e.g.:

mts_dispatchers="(address=(protocol=tcp)(host=xxx)(port=2500))(dispatchers=1)"
mts_dispatchers="(address=(protocol=tcp)(host=xxx)(port=2600))(dispatchers=1)"

In the above example, the firewall must be configured to open TCP/IP ports
2500 and 2600.

II / Oracle7 (7.x) - Unix: Firewall with Network Address Translator (NAT)

-------------------------------------------------------------------------
1 - In dedicated server mode, Unix natively implements TCP/IP sharing, so
there should be no problem with connectivity.
2 - For MTS Mode, there is no solution other than to use a sqlnet proxy
such as a firewall.

III / Oracle8/8i (8.x) - Unix: Firewall without Network Address Translator (NAT)
---------------------------------------------------------------------------
1 - In dedicated server mode, Unix natively implements TCP/IP sharing, so
there should be no problem with connectivity.
2 - For MTS mode, you may configure MTS to use specific TCP/IP ports e.g.:

mts_dispatchers="(address=(protocol=tcp)(host=xxx)(port=2700))(dispatchers=1)"
mts_dispatchers="(address=(protocol=tcp)(host=xxx)(port=2800))(dispatchers=1)"

In the above example, the firewall must be configured to open TCP/IP ports
2700 and 2800.

OR

you may install and configure Connection Manager (CMAN) provided natively
as part of Net8 from Net8 (8.0.3) onwards.
IV / Oracle8 (8.x) - Unix: Firewall with Network Address Translator (NAT)
------------------------------------------------------------------------
1 - In dedicated server mode, Unix natively implements TCP/IP sharing, so
there should be no problem with connectivity.
2 - In MTS mode, you may configure Connection manager (CMAN).

V / Oracle7 (7.x) - Windows NT: Firewall without Network Address Translator (NAT)
-------------------------------------------------------------------------
There is no solution other than to use a sqlnet proxy such as a firewall.

VI / Oracle8 (8.x) - Windows NT: Firewall without Network Address Translator (NAT)
-------------------------------------------------------------------------
Unlike Unix, Windows does not implement TCP/IP port sharing by default.
When using either dedicated or MTS mode, registry parameter USE_SHARED_SOCKET=TRUE
may be set in the Windows registry. The location of the parameter varies and
depends on the Oracle version. For registry location details, refer
[NOTE:124140.1],
which also discusses other methods to set the parameter.

VII / Oracle8 (8.x) - Windows NT: Firewall with Network Address Translator (NAT)
-------------------------------------------------------------------------
1 - In dedicated server mode, set registry parameter USE_SHARED_SOCKET=TRUE.
2 - In MTS mode, you may either configure Connection manager (CMAN)

OR

configure MTS to specify particular TCP/IP port/s.

Other Porting Restrictions

==========================
Oracle 7 RDBMS: OS/2 (No support for MTS), NetWare (No support for MTS) ,VMS
Most desktop platforms did not support MTS connections in Oracle 7.
Oracle 8/8i RDBMS: NetWare (Supports MTS as of 8i), VMS

ADDITIONAL INFORMATION
----------------------
In 8.1.7.0.0, parameter USE_SHARED_SOCKET no longer works due to [BUG:1566794].
However, the bug is fixed in Oracle Server patchset 8.1.7.2.0 onwards.
Refer [NOTE:124140.1] for details.

RELATED DOCUMENTS
-----------------
[NOTE:124140.1] How to configure USE_SHARED_SOCKET on Windows NT/2000
[NOTE:66382.1] Firewalls, Windows NT and Redirections
[NOTE:2077721.6] Installation and Configurationfor Net8 Connection Manager
Net8 Administrator's Guide

Solution: How to configure USE_SHARED_SOCKET on Windows NT/2000

---------------------------------------------------------------
PURPOSE
-------

The net8 connection to a Windows NT/2000 database server normally redirects

the port number to a random number when a user process connects to a ORACLE
shadow process. It does not use the TCP/IP port sharing like on UNIX
systems where the clients only need to know the TNS listener port.
In order to make Oracle connection to work in a firewall environment, the
customers had to get a firewall that has a SQL*Net proxy built in or
with the newest TCP/IP Socket implementation of Windows NT 4.0 (available with
Service Pack#3) and Windows 2000 this can now be handled by the use of the
parameter "USE_SHARED_SOCKET".

SCOPE & APPLICATION

-------------------

This bulletin is intended for database and network administrators who need
to enable SQL*Net/Net8 database connections via a firewall to Windows NT or
Windows 2000 based databases.

How to enable USE_SHARED_SOCKET on WINNT and Windows 2000

---------------------------------------------------------
As described in Note:66382.1 there is 2 ways to make ORACLE
work in a firewall environment.

This can be handled by applying a firewall that has a SQL*Net proxy built in.
The way this works is that the SQL*Net proxy starts another listening process
(usually on port 1610). This causes the firewall to act like a Connection
Mananger or Multi Protocol Interchange.

The second way to resolve this issue is to upgrade the server to 8.0.x or 8.1.x
and to set the USE_SHARED_SOCKET parameter in the registry in order to
activate port sharing under WINNT. The parameter is available in Windows NT 4.0
(SP3 or higher) and Windows 2000 when Winsock 2 support is installed. With this
method, it is also possible to use firewalls which only supports port filtering
and no SQL*Net proxy. At least for dedicated connections. Multi Threaded Server
(MTS) still needs to redirect the connection to a dynamic port and therefore
requires a SQL*Net proxy.

In Windows NT port sharing can be activated by setting

USE_SHARED_SOCKET = TRUE

in the system environment (Control Panel, SYSTEM environment). I Windows 2000

this is done also by the SYSTEM button in the control panel, but
environment variables are specified and found by clicking the "Advanced"
button.

The parameter can also be set within the WINNT registry under
\\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE (Relases 8.0) or
\\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME<#> (Release 8i )

Both methods require a shotdown/startup of the nt server

EXAMPLE of configuration
-------------------------
Tnsnames.ora
Example_shared_socket =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =<nodename>)(PORT = 1500))
)
(CONNECT_DATA =
(SERVICE_NAME =<sid>)
)
)

Listener.ora

LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <nodename>)(PORT = 1500))
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = <global db name if used>)
(SID_NAME = <sid>)
)
)

Troubleshooting notes
----------------------
A successful configuration can be seen using the 'netstat -a' command from a
Command Prompt

OR

Analyze a client trace by setting folloving parameters in the client SQLNET.ORA

TRACE_LEVEL_CLIENT= 16
TRACE_DIRECTORY_CLIENT = <directory>
TRACE_FILE_DIRECTORY= <filename>

By searching for the string 'port' in the trace file, the only port seen is
the one specified.

The listener can be stopped without interupting the connected sessions, but it
cannot be restarted without forcibly disconnecting connected sessions first.

Special Note:
=============
If using TCPS protocol or SSL, port re-direction will occur. The only
solution is to use firewall vendor that supports Sqlnet/Net8 connectivity or
configure Multi-Threaded Server (MTS).

RELATED DOCUMENTS
-----------------
Note:66382.1 FIREWALLS, WINDOWS NT AND REDIRECTIONS
Note:1012783.102 THE COMPLETE TNS-12203 FOR TCP BULLETIN

Bug:1566794 CONNECTIONS FAIL WITH ORA-12537 WHEN USE_SHARED_SOCKET IS SET IN 8.1.7

(a fix for this bug is being tested at the moment)
Solution: Firewalls, Windows NT and Redirections
------------------------------------------------

PURPOSE

To explain how firewalls work when a Windows NT server is involved.

RELATED DOCUMENTS
[NOTE:45226.1] SQL*Net and Firewalls

Firewalls, Windows NT, and Redirections:

========================================

On Windows NT, when a connect request comes in to the listener, the listener
spawns an Oracle thread. This thread is a listening thread and is started
on a wild-card address, meaning that the thread is listening for connections
on the current IP address and an unused port number given to the thread by
the networking software. The Oracle thread will contact the listener using
IPC and inform the listener of its listening address, connection load, and
some other status information. The listener sends back to the client a
REDIRECT address. This tells the client to reconnect to the newly spawned
Oracle thread. Since this Oracle thread is on a random port (a range of ports
cannot be defined), the firewall will not let the connection through.
The resulting error is usually a TNS-12203.

There are two ways to resolve this issue:

(i) The first way is to use a firewall that has a SQL*Net proxy built into
it. The way this works is that the SQL*Net proxy starts another listening
process (usually on port 1610). This causes the firewall to act as a
Multi-Protocol Interchange. So, by using the "tnsnav.ora" file on the
client, you connect to port 1610 (the firewall). The firewall passes the
connection to the server. The server gives a redirect to the client. The
client reconnects to the firewall proxy on port 1610, and the firewall
passes the connection to the Oracle thread on the wild-card listening
address. Here's what the connection flow would look like:

1. connect to proxy and pass connection to listener

2. send redirect to client
3. connect to redirected address via the proxy
4. oracle accepts the connection

firewall
||
+------+ <--------2--------||-------2------ +---------+
|client| || |listener |(port=1521)
+------+ --------1------> proxy ----1------> +---------+
A \ /||\
| \---------3-------/ || \-----3------> +---------+
| || | oracle |(port=xxxx)
+--------------4---------||-------4------- +---------+

(ii) The second way to resolve this issue is to upgrade the server to 8.0.x
and use the USE_SHARED_SOCKET parameter in the registry. With this
 method, it doesn't matter what kind of firewall you have. The syntax
for this parameter is:

USE_SHARED_SOCKET = TRUE

Place the parameter in the registry under HKEY_LOCAL_MACHINE:Software:

Oracle

Restart Oracle and the listener for the parameter to take effect.

Here's how USE_SHARED_SOCKET works. The listener binds and creates a

socket on the address specified in the "listener.ora" file. On this
socket, there is a LISTEN state active that is used by the listener.
When a new connection comes in to the listener, the listener spawns an
Oracle thread on the listening port (i.e. 1521). This happens over and
over again so that you have a listener and several established
connections using port 1521. Pictorially this scenario would look like
this:

+---<O>--------<O>----<O>---<O>--+
| |
| This square represents <O>
| a listening socket for |
| port 1521. |
<O> |
| <O> = oracle thread <O>
| <L> = listener |
| |
+-<O>-------<L>--<O>------<O>----+

The operating system then does a poll() or a select() on the socket to

test for any data. If any of the threads have data, a signal handler is
used to contact the application and inform it of the new data.

The disadvantage of USE_SHARED_SOCKET is that if the listener shuts down,

all connections are dissolved.

Finally, a very common question concerning the listener and port numbers is
why different port numbers show up in the "listener.log" file. What you are
seeing is the client's source port and client's source IP address. Here is
how this relates to your firewall:

If I want to make a TCP connection to a server (say with TELNET), I need

to create a socket. To create a socket, I need 4 pieces of information:
a source IP and port, and a destination IP and port. So, using TELNET as an
example (the listening port for the TELNET process is 23 on the server):

source destination
+-----------+---------------+
IP |138.2.12.8 |185.45.67.53 |
+-----------+---------------+
port | xx | 23 |
+-----------+---------------+

Notice I have labeled the source port as 'xx'. What happens is that the
networking software on the client chooses at random, or in sequential order,
a valid port (between 1024 and 65535) so the client can send and receive data.
This is what you are seeing in the "listener.log" file.
Question: Will this be a problem with the firewall?
Answer: No. The firewall will restrict incoming connections, but will
freely let any connection on any port out (which is okay).

Here is what it might look like:

Firewall
<-------------||---------\
<-------------||---------\\
[CLIENT]----------------->|| \---[SERVER]
<-------------||---------//
<-------------||---------/

Search Words:
=============

ORA-12203

Solution: Connecting to Database Through a Network Address Translator (NAT)

---------------------------------------------------------------------------

PURPOSE
-------

To discuss the issues of connecting to an Oracle database through a Network

Address Translator (NAT) and to provide a method for working around the issues.

SCOPE & APPLICATION

-------------------

External.

DESCRIPTION
-----------

A Network Address Translator (NAT) basically acts as a router connecting two

networks together; one of these networks (designated as inside) uses private
IP addresses that need to be converted into legal IP addresses before packets
are forwarded onto the other network (designated as outside). Essentially you
end up with external IP addresses that are translated to internal IP addresses
and vice versa.

PROBLEM
-------

Clients that reside outside of NAT router can only access systems inside the
NAT router by using their external IP addresses. In this situation, the server
where the Listener resides is assigned an internal IP address. The client
successfully connects to the listener through the NAT by referencing the
external IP address of the server. The Listener then spawns a dedicated server
process and sends a redirect address back to the client to connect to. The
redirect address includes the internal IP address of the data server.
When the client attempts to connect back to the redirect address, it fails
because the client can only use the external address of the server. This is an
issue affecting both Unix and Windows databases.

NAT
external IP | internal IP
addresses | addresses
------ (192.168.255.x ) | (10.1.54.x) --------
|client|------------------>>>|>>>------------------|database|
------ | --------
|
NAT

SOLUTION
--------

This problem can be resolved by installing Oracle Connection Manager (CMAN) on

the internal network, and using it as a SQL*Net/Net8 connection proxy. In this
scenario, clients connect to CMAN, who then completes the connection to the
database. When connections are routed through CMAN, the redirection to the
dedicated server process is isolated to the internal network. All the client
ever sees is a connect and accept packet, thereby eliminating the network
address translation problem.

NAT
external IP | internal IP
------ addresses | addresses ---------- --------
|client|----------------->>>|>>>------------|connection|------|database|
------ | | manager | --------
| ----------
NAT

The key to making this work is the placement of the IP addresses. The external
and internal addresses must be specified in the proper locations.

SAMPLE CONFIGURATION
--------------------

Given the following network diagram, the following configuration is based on a

working CMAN/NAT environment. The diagram assumes TCP port 1610 to be open on
the Firewall/NAT Router:

Client:
External IP address: 192.168.255.3.

Firewall/NAT Router:
External IP address: 200.1.255.1.

Connection Manager:
Internal IP address: 10.1.54.134.
NAT IP address: 200.1.255.5.

Data Server:
Internal IP address: 10.1.54.127.
NAT IP address: 200.1.255.10.
#TNSNAMES.ORA:
ORCL.WORLD =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=200.1.255.5)(PORT=1610)) # external IP address
(ADDRESS=(PROTOCOL=tcp)(HOST=10.1.54.127)(PORT=1521)) # internal IP address
)
(CONNECT_DATA=
(SID = ORCL)
)
(SOURCE_ROUTE = yes)
)

#CMAN.ORA
CMAN =
(ADDRESS_LIST =
(ADDRESS =(PROTOCOL=tcp)(HOST=10.1.54.134)(PORT=1610)) # internal IP address
)

#LISTENER.ORA:
LISTENER =
(ADDRESS_LIST =
(ADDRESS= (PROTOCOL=tcp)(HOST=10.1.54.127)(PORT=1521)) # internal IP address
)
SID_LIST_LISTENER =
(SID_LIST=
(SID_DESC =
(ORACLE_HOME= /u01/app/oracle/product/8.1.7)
(SID_NAME = ORCL)
)
)

NOTES
-----

Beware of using access control with CMAN and NAT addresses. The CMAN_RULES
section of the CMAN.ORA uses source and destination IP addresses to limit
access to services. Since NAT is being used, the source and destination
addresses may not be correctly interpretable by CMAN, thus causing ORA-12204
error when connecting from the client.

The configuration described in this note will only work if the NAT server has
port forwarding enabled. A number of the more popular NAT servers have this
feature disabled by default.

RELATED ARTICLES
----------------

[NOTE:2077721.6] Installation and Configuration of Net8 Connection Manager (CMAN).

[NOTE:131524.1] Firewalls on Windows and Unix - Oracle versions 7.x, 8.0.x, 8.1.x.