首页 > Linux操作系统 > Linux操作系统 > Firewalls, Windows NT and Redirections

Firewalls, Windows NT and Redirections

原创 Linux操作系统 作者:NinGoo 时间:2019-03-29 14:57:04 0 删除 编辑

Doc ID: Note:66382.1 Type: BULLETIN
Last Revision Date: 03-JUN-2005 Status: PUBLISHED


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

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

+------+ <--------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:


Place the parameter in the Windows registry under the following locations:

Restart the system 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 square represents
| a listening socket for |
| port 1521. |
| = oracle thread
| = listener |
| |

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 | | |
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:

[CLIENT]----------------->|| ---[SERVER]

Search Words:


来自 “ ITPUB博客 ” ,链接:,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录


  • 博文量
  • 访问量