Results 1 to 4 of 4
  1. #1
    Join Date
    Sep 2002
    Posts
    4

    Question Unanswered: tnsping works but session can't establish

    I hope someone can help out on this. I am trying to connect to a Oracle 8.1.7 database on a remote server. The SID and Listener are fine as I can TNSPING and establish a session if I am VPN'd to the remote machine. My question is, why can I not establish a database session without being VPN'd? TNSPING works without VPN, but I recieve a TNS time out if I try to connect without the VPN session established.

    Scott

  2. #2
    Join Date
    Mar 2002
    Location
    Ireland
    Posts
    181
    I am not familiar with VPN.

    What operating system is the remote db on.
    There is a value on Windows machines in the system environment (use_shared_socket) that may need to be changed (I think it has to be set to True.)
    This would explain why you can TNSPING but cannot connect.
    The remote db could be telling the session to connect on a port other than 1521 (this would only make sense if there is a firewall betweenthe two.)

    If not - can you confirm the username / password just to be sure.

    Let me know,
    Breen.

  3. #3
    Join Date
    Sep 2002
    Posts
    4
    Breen,

    Thanks for pointing out the other item. I am running on NT 4 SP6 and have tried using the USE_SHARED_SOCKET entry in the registry under HKLM...ORACLE without luck. Although after more searching for answers uncovered a post that states this will not work with 8.1.7 and that is the version I am on, which from the post means I need to patch to 8.1.7.2 for this entry to work. Guess I will see if I can do that and try again.

    Scott

  4. #4
    Join Date
    Sep 2002
    Location
    ITALY
    Posts
    53
    Hi Scott.
    Your problem is a classic one, but has many ramification, so your solution depends on your configuration.

    The key problem is this:
    the listener answers to the client WITH a REDIRECT message that points the server endpoint - a socket-, that has a form of an (IP:PORT) couple or a (host:PORT) or sometimes a (-:PORT) in which the host specification is left unspecified.
    That is the location where a dispatcher or server is waiting for the requests to income.
    The redirect message is sent only when the client needs to establish a session, and not at the tnsping level (which is testing only the transport level, not the session one).

    Where the problems arise?
    All the problems arise in the specification of the HOST part of the socket,
    because older releases sent back the IP, failing when client and server are on local nets connected by a NAT that mask the address; in fact the listener send back the address of his local (usually 10 or 192.168 networks) - "the remote for you" - lan not the "natted" ip of your local lan with which you are adressing the server.
    Next oracle's listener release changed the IP with the hostname, but sometimes the domain name is missing and so the dns search (gethostbyname) can fail or return a wrong result -a server with the same hostname in your dns server/hostname file-.

    Your situation is this: if you are in VPN you are "logically" in the same net as the server or a "glued net", so all is working fine.
    If you are not in the VPN, you are out of the FW/NAT address translation and so: which address do you have locally/in which net are you?
    This is the key question!
    Trace the tns session and look at the redirect message the listener is sending to you, so you can see where you are redirected (probably the ports used by oracle are not opened by NAT/FW unless you are in VPN).

    I apologize myself for the explanation,
    the idea is quite simple but usually is mixed in a complicated framework and it's difficult to answer without knowing the details of your environment.

    Good luck!
    Franco Ceotto
    SIPTI srl
    OnSite Services
    9i OCP DBA, Performance Engineer

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •