Solving Firewall Problems on Windows ... ...

Solving Firewall Problems on Windows (Doc ID 68652.1)

To Bottom

---

APPLIES TO: Oracle Net Services - Version 2.3.4.0.0 to 11.2.0.2 Generic Windows Checked for relevance on 5-DEC-2012. TNS-12535 USE_SHARED_SOCKET PURPOSE This article describes how to get around firewall problems with SQL*Net or Net*8 on Windows servers. SCOPE SCOPE & APPLICATION A firewall is a secure gateway that controls the traffic into and out of a company's internal network. Firewalls can cause problems when a SQL*Net client outside the firewall tries to connect to an Oracle database on Windows NT inside the firewall, or vice versa. The default Oracle Listener listens on port 1521. It may not be sufficient to configure the firewall to allow access through port 1521 so the SQL*Net clients will be able to connect. To understand why the TNS connect will fail, it is necessary to understand how a SQL*Net connection on Windows NT works. When a client initiates a TNS connect, a TCP connection is established with port 1521. A TNS CONNECT packet is then sent to the listener. On UNIX systems the listener process will fork a new Oracle process to deal with the new incoming connection. With UNIX, forked processes will inherit the resources owned by the parent process such as the file handle that represents the TCP socket. In Windows NT, the Listener tells the Oracle Service to spawn a thread. Earlier releases of SQL*Net for Windows NT used the WINSOCK V1.1 API. With this version of WINSOCK there is no capability of passing a TCP socket between two processes, such as from the Listener to the Oracle Service, and so there was no way to inherit the TCP socket. This restriction forced the client to have to create a new TCP connection to the new thread. To do this, the thread randomly selects a new TCP port to use for the connection request, for example port 10087, and informs the listener to redirect the Client to it. The listener now informs the client that they need to REDIRECT the connection attempt to this newly selected networking endpoint. The listener does this by sending a TNS REDIRECT packet to the client with details of the new port to reconnect to. The client drops the existing TCP connection and issues a TCP Connect sequence to the new TCP port, followed by a TNS Connect packet. The server thread accepts the TCP connect and responds with a TNS ACCEPT packet. The Client exchanges various TNS packets and then logs into the Database. So, if you create an Access Control List (ACL) on the firewall to allow connects through port 1521, after the REDIRECT packet has been sent to the client and the TCP connection to port 1521 is closed, the firewall will not allow the TCP connection to port 10087 so the TNS connection will fail. As the REDIRECT port that gets generated is entirely at random, it would not be secure to allow connections to this random port range in the firewall as it begins to defeat the purpose of the firewall. DETAILS note:62528.1note:62528.1 /To resolve this problem there are several options: This step should only be performed by the firewall administrator and only if they feel this is a viable workaround for their company. Otherwise, skip to step 2. This would be to configure ACL on the firewall to limit IP addresses rather than port numbers. This is not a very secure option. Use Oracle Connection Manager. Oracle Connection Manager will "absorb" the REDIRECT as it all occurs on the server side of the firewall. For further information on Connection Manager and how to configure it, refer to Note 62528.1. If you are on Oracle version 8 or higher on the Database, you can use the WINSOCK V2 API feature of Shared Sockets. This allows a socket to be shared (or passed) between processes. To use this functionality in a single Oracle Home, under the Registry key HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE create USE_SHARED_SOCKET as a STRING_VALUE and set it to TRUE. If you are running multiple Oracle Homes, view the %ORACLE_HOME\bin\oracle.key file to find which registry key to add the parameter USE_SHARED_SOCKET. Please see Note 124140.1 for greater detail on this Windows feature. WARNING: When using this method you must restart all Oracle processes for them to pick up the registry change. Note: This parameter only works in dedicated server mode in a TCP/IP environment and will not work for the Multi-Threaded Server (MTS) configuration. To spawn a dedicated server for an instance of Oracle Database not associated with the same Oracle home as the listener and have shared socket enabled, you must also set the parameter USE_SHARED_SOCKET for both Oracle homes. Note: If this parameter is set, you cannot use a version 8.0 or later listener to spawn Oracle7 release 7.x databases. Note: USE_SHARED_SOCKET was introduced in Oracle version 8.0. It was set off by default in 8.0 to 10.0. The default is set to true in 10.1 and later. This parameter is planned to be deprecated in a future release. REFERENCES NOTE:62528.1 - Using Connection Manager (CMAN) as a MultiProtocol Interchange (MPI) NOTE:124140.1 - How to configure USE_SHARED_SOCKET on Windows NT/2000