SQLNet through a firewall

[John Hartley]

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
jhar...@scc.com

[Sybrand Bakker]

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 <jhar...@scc.com> wrote in message
news:Vm_V3.6687$d6.1...@newsr2.maine.rr.com...

[John Flack]

SQL*Net (Net8 too) over TCP/IP works like this:

The client program asks SQL*Net to establish a connection.
SQL*Net looks up the connect string in TNSNAME.ORA, and finds the IP address
and port to use. Then it sends a connect request to the listener.
LISTENER.ORA configures the listener to listen on a particular port for
requests to connect certain databases. When it gets a request, it starts a
shadow process for the user and connects that process to the proper
database. It hands the process a randomly selected port for the continuing
connection to use, and informs SQL*Net on the client.
Then the listener gets out of the way, and resumes listening for the next
connection. Notice that the connection is no longer using the port on which
it was started.

So you have to configure the firewall so that it will allow traffic on any
port, PROVIDED that the original connection was on the listener's port.
This is a fairly common situation on TCP/IP, and you should be able to find
a good example of it in your firewall's manual. I think either ftp or
telnet work this way, but I forget which.

[Greg Stark]

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" <postm...@sybrandb.demon.nl> writes:

--
greg

[Greg Stark]

"John Flack" <JCF...@prodigy.net> writes:

> It hands the process a randomly selected port for the continuing connection
> to use, and informs SQL*Net on the client. Then the listener gets out of the
> way, and resumes listening for the next connection. Notice that the
> connection is no longer using the port on which it was started.

This is only true of MTS connections. Dedicated servers continue to use port
1521 or whatever you have configured.

> So you have to configure the firewall so that it will allow traffic on any
> port, PROVIDED that the original connection was on the listener's port.
> This is a fairly common situation on TCP/IP, and you should be able to find
> a good example of it in your firewall's manual. I think either ftp or
> telnet work this way, but I forget which.

FTP works like this, which is why firewalls often require you use passive ftp
to get through. MTS connections are kind of like passive ftp except you're
probably trying to get _into_ a protected subnet rather than out of one, so
it's backwards from what you need.

I use a TNS entry like this to tunnel TNS connections across ssh which is a
similar problem -- and a little encryption is not a bad idea if you're going
to be punching holes in firewalls.

SSH =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = tcp.world)
(PROTOCOL = TCP)
(Host = localhost)
(Port = 1522)
)
)
(CONNECT_DATA = (SID = MYSID)
(SRVR=DEDICATED)
)
)

--
greg