Re: SQL*Net and firewalls

netac <netac_at_worldnet.att.net> wrote in article <32F0E0CC.7146_at_worldnet.att.net>...
> Harold Lockhart wrote:
> >
> > Enrico Badella wrote:
> > >
> > > I have been told that there are problems getting SQL*Net thru
 firewalls
> > > but no reason was given.
>
> SQLNET does use fixed ports, 1526 (V1), 1526 (V2), 1527 (NAMES). The
> traffic on these port(s) is separate from wanting to secure the login
> session. For this, you can go all the way from clear text, to whatver
> encryption is supported natively by Oracle, to third party security (ala
> SecurID/ Kerberos) supported by Oracle SQLNET V2.

Yes there is a problem with passing SQL*Net traffic though a firewall.  

You might want to check that again and actually trace some SQL*Net traffic. At least on Oracle servers the client will connect on port 1521, 1526, or whatever port you define. The server then tells the connection a hostname (ip address) and a port number (randomly out of a range or numbers that there are listeners listening on those port numbers) and then tells the client to reconnect and connect back on the hostname (ipaddress) and port number that it gave it. There's actual two methods that are commonly used to connect, Dedicated Server and Multi-Threaded Server. Both are simliar in that they tell the clients what ip address/port number to reconnect
to.

We've done a lot of checking on this where I work and with Oracle and we also discovered that SQL*Net uses entirely different port ranges between HP and Sun Unix machines for their listeners. The HP machines usually started up listeners in the 15xx range and I think Sun was somewhere around the thirty thousand range (I'd have to dig that one up again).

Oracle is writing a proxy to pass SQL*Net traffic for various platforms and

firewalls, so you probably need to talk to your firewall company to see if they
have it available. Oracle writes their code on Sun machines though, so those
are usually available first.

Ron Atkinson Received on Fri Jan 31 1997 - 00:00:00 CST