Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: SQLNet through a firewall

Re: SQLNet through a firewall

From: Greg Stark <greg-spare-1_at_mit.edu>
Date: Fri, 12 Nov 1999 19:44:40 GMT
Message-ID: <87so2bv6jk.fsf@HSE-Montreal-ppp19485.qc.sympatico.ca>

Do you have MTS configured?

If so you'll either have to add whatever ports the dispatchers have chosen to use, which will be hard to automate, or tell the client to use a dedicated server.

"Sybrand Bakker" <postmaster_at_sybrandb.demon.nl> writes:

> sqlplus doesn't use sqlnet at all...
> Sorry but this is blatant nonsense period.
>
> By default the connection from server to client will use a different
> randomly selected port other than 1521 or 1526 or whatever you choose. In
> Oracle 8i you should be able to have them on one port by using the line
> use_shared_sockets = true
> in sqlnet.ora
>
> TNSPing80 only checks for the existence of the listener. It doesn't try to
> connect.
> You should definitely have the address of the database only.
>
> Hth,
> --
> Sybrand Bakker, Oracle DBA
>
> John Hartley <jhartley_at_scc.com> wrote in message
> news:Vm_V3.6687$d6.10698_at_newsr2.maine.rr.com...
> > Hello -
> >
> > I'm attempting to connect to an Oracle 8i server from a Windows Terminal
> > Server using Metaframe Client ver 1.8.
> >
> > We are using Raptor as our firewall. In a nutshell, we have configured
> the
> > TNSNAMES.ORA to have the IP address of the Oracle DB Server as well as the
> > firewall address.
> >
> > I can TNSPing the SID from the Citrix machine(which is on a different
> > segment of our LAN...Think of it as outside the firewall..) But, I cannot
> > establish a SQLPlus session. I get an ORA-12203...TNS unable to connect
> to
> > destination error! i thought that TNSPing uses is more of a verifiable
> > connection that SQLNet was working versus SQLPlus, because SQLPlus doesn't
> > use SQLNet AT ALL!!
> >
> > My listener is set up on 1530, because 1521 we thought was deemed
> > proprietary, in any case, we got the same error with 1521 and 1526 on the
> > listener.
> >
> > We have traced this and it looks like the port that the listener is
> sending
> > back info on is refusing the packet.
> >
> > Any ideas of hwere to look??? I'm pulling whats left of my hair out!!
> >
> > Thanks - John
> > jhartley_at_scc.com
> >
> >
>
>

--
greg Received on Fri Nov 12 1999 - 13:44:40 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US