Madhur,
The Oracle SQL*Net protocol, though technically proprietary, is fairly well
understood and is parsed by several firewalls to be able to open and close
ports at the correct times.
SQL*Net v2 (also known as the Transparent Network Substrate or TNS -- and
recently replaced by the moniker Net8) is used as a session-layer protocol
on top of TCP between Oracle clients and Oracle Servers. SQLPlus is an
Oracle Client.
The SQL*Net protocol acts as a "wrapper" in which the actual client <->
server commands ride. Using a sniffer to decode those packets, you can
actually see SQL statements in the TCP payload, but after a bunch of
overhead octets. Those overhead bytes are defined in the SQL*Net protocol.
The SQL*Net protocol specifies several types of protocol messages,
including a "redirection" message -- much like FTP's PORT mode.
For various reasons, older versions of Oracle server required that the
client connect to the server on a single fixed port (usually TCP/1521), and
perform some initial negotiation, after which the client was informed as to
a new, ephemeral port on which to connect for the actual data transaction.
This redirection message is the one which must be parsed by the firewall to
correctly open.
Once the redirection message is received at the client, it will make a new
TCP connection to the server, on the new port. (The protocol allows
connections to other servers, too, but this function is relatively unused.)
In order for this second connection to (securely) pass through a firewall,
a packet filtering firewall must have created a "pinhole" for the correct
addresses and ports to pass through -- but only for the duration of the
session. Once that session ends, the hole must seal itself up.
Note that this problem can go away if you upgrade to Oracle 8 -- it has the
ability to use the initial port for data, without issuing a redirection
message.
Some packet sniffers can actually decode the TNS/SQL*Net protocol and show
you the contents of the messages, like the Shomiti Surveyor (www.shomiti.com).
The SQL*Net problem is actually one of a class of problems that typically
plague packet filtering firewalls. The latest (and nastiest, so far) is
H.323 and related protocols, which require several "pinholes" to be opened
in different directions through the firewall.
Most modern packet filtering firewalls support passing SQL*Net "securely",
including the Lucent Managed Firewall, Checkpoint's Firewall-1, and Cisco's
PIX firewall.
You didn't specify which firewall you were using, so I can't help you more
specifically.
Hope this helps!
-david
At 08:35 AM 2/23/2000 , netcomm wrote:
>hi all
>
>I need to permit oracle client to connect to oracle server behind a
>firewall...i opened port 1521 and 1526.....but the client is not able to
>access..
>when he runs sql+ it opens incremental ports ...upto 5000....
>
>how to securely permit this....
>
>any info or pointers r welcome
>
>TIA
>
>Madhur Nanda
>
-------------------------
David J. Cavuto, Systems Engineer
[EMAIL PROTECTED]
Lucent Security Products - http://www.lucent.com/security
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
