Re: Remote login

From: Karsten Farrell <kfarrell_at_belgariad.com>
Date: Fri, 22 Nov 2002 17:08:13 GMT
Message-ID: <1wtD9.2702$Cz1.82346166@newssvr14.news.prodigy.com>

Singnet Newsgroup wrote:

> Your guess is right.
> I am able to perform a TNSping to the server.
> However, when I start the test connection from NET8 Assistant, I encounter
> TNS:protocal adapter error.
> All linkage seems OK but when tested, it fails.
> I was wondering if the failure was due to the NAT at the firewall or router
> ?
> What do U think?
> I don't have a metalink account.
> Would appreciate, if it is possible, to summarize it for me.
> Thanks a lot.
> bye
> 
> "Karsten Farrell" <kfarrell_at_belgariad.com> wrote in message
> news:VA8D9.2038$uy7.43823309_at_newssvr14.news.prodigy.com...
>

>>Singnet Newsgroup wrote:
>>
>>>Hi,
>>>
>>>I need to setup a remote site. It is to come in thru internet.
>>>I had managed to setup the public address.
>>>When I connect, I am able to ping the server.
>>>However, when I run the client copy of the application, I cannot get
>>

> logon
> 


>>>to the oracle database.

>>>Is there some port that I need to open on the firewall?

>>>Is there other things that I need to look at?

>>>

>>>Bye
>>>
>>
>>Let's see if I can word this correctly (been slammed in the past):
>>
>>1. Client contacts Listener (on server) on specified port (default
>>1521). You can 'tnsping net_service_name' to verify that the Listener is
>>alive and well (and willing to communicate).
>>
>>2. Listener starts another process on the server to communicate with the
>>Client. This other process chooses a random port over which it carries
>>on the network conversation with the Client.
>>
>>If you have a Metalink account (requires you to supply your CSI), look
>>for Note 125021.1 "Oracle Connectivity with Firewalls". You can also
>>search Google using the keywords "oracle firewall".
>>
>>

>
Here's a very brief summary of Note 125021.1 (hope I'm not violating any copyrights). :)

A 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 = c:\temp   [or any other valid directory]

Now connect with sqlplus to force the error. Look for the 'nsprecv: packet dump' line. It will be followed by a hex/ascii dump that will show the port change. You can also see it in the 'nttbnd2addr: port resolved to n' line.

The port that is assigned to the client is randomly chosen by the o/s and *can't* be modified. It can be *any* free port available that the server determines is not in use.

Once you have determined that the problem is the firewall causing the connection to fail, the next step is to select a solution to resolve the issue.

*Solution*: Contact firewall vendor to see if they have an upgrade that knows about Oracle's port redirection.

*Solution*: Use Oracle Connection Manager. Configuring this is somewhat complex and is covered in the doc set.

*Solution*: For NT clients, add 'use_shared_socket = true' to registry. This forces all clients to stay on port 1521 (no port redirection). However, if the Listener is stopped (for whatever reason), everyone loses their connection (which is probably why port redirection was invented in the first place ... so I can restart the Listener without dumping everyone).

For some Unix clients, you can encounter problems similar to NT clients if you've implemented MTS (Multi-Threaded Server).

*Solution*: Set up specific MTS ports in your init.ora file. This forces the dispatchers to use the specified ports instead of assigning random ports. This can be effective in SSL connections.

There's more ... and links to related Notes. But I didn't want to type or cut/paste the whole thing. :) Received on Fri Nov 22 2002 - 11:08:13 CST