Re: Remote login

From: Singnet Newsgroup <stcheong_at_mbox2.singnet.com.sg>
Date: Mon, 25 Nov 2002 21:40:00 +0800
Message-ID: <art7ms$3d9$1@reader01.singnet.com.sg>

Yes, the NAT seems to be presenting the problem. I would like to try setting up the Configration manager. However, I am not sure if it is better to put it at the remote client or the server's end.
Can I configure it at the remnote client? This way, I don't have to change the setting in the current "LIVE" server.

Need your advice .

Bye

"Karsten Farrell" <kfarrell_at_belgariad.com> wrote in message news:1wtD9.2702$Cz1.82346166_at_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 Mon Nov 25 2002 - 07:40:00 CST