Re: Question: traversing a firewall with Oracle 9i R2.

"Dave Sisk" <dsisk_at_nc.rr.com.0nospam0> wrote in message news:<xhMac.38677$zy.375295_at_twister.southeast.rr.com>...
> Doug:
>
> If I understood what you are trying to do correctly, just opening port 1521
> in your firewall won't do the trick. The TNSListener listens on port 1521
> (by default, you can configure it to listen on a different port, of course).
> When it gets a connection request on that port, it accepts the connection,
> then asks the database server to spawn a process to handle the connection on
> some available port on the host. The TNS Listener then instructs the client
> to disconnect from it on 1521 and reconnect to the port this server process
> that it just spawned is listening on.
>
> This is the default behavior, but there are ways to modify it. I don't
> recall the details at the moment, but I do recall that having the SQL*Net
> proxy on the firewall greatly simplifies things. Start with that piece!
>
> HTH,
> Dave
>
>
> "Doug Whittier" <dwhittier_at_shaw.ca> wrote in message
> news:fe1f89a3.0403301650.49179e52_at_posting.google.com...
> > Hi, all.
> >
> > I'm reasonably versed in network issues, but am fairly new to Oracle.
> >
> > I am attempting to configure a connection over two firewalls, allowing
> > client communication to my 9i database server (NOT Forms).
> >
> > I am addressing this connection problem one firewall at a time, and
> > have placed a client outside the firewall that is nearest to the
> > database server. I believe that the firewall which would be closest to
> > the client machines is running SQLNet Proxy, but I'm not really sure
> > yet. First things first.
> >
> > I have opened up port 1521 between the client (external) and server
> > (internal)IP Addresses.
> >
> > The firewall acts as a proxy, and does not do true Address
> > Translation. The firewall redirects traffic from a routable address on
> > the Internet to a non-routable address inside. This routable address
> > is what is made available to incoming client connections (it's what
> > you'd put in your tnsnames.ora file as the HOST).
> >
> > I try to connect from outside the firewall, and my client simply times
> > out.
> >
> > I did a TCP dump on the server, and it looks as if what the server
> > sees is an attempt from a client to connect to THE SERVER'S PUBLISHED
> > ROUTABLE ADDRESS, rather than what it sees as its true internal
> > address. This is in fact what I'm trying to do, but the firewall isn't
> > changing the destination address inside the packet to reflect the true
> > address of the server.
> >
> > I understand that I should be using Connection Manager to facilitate
> > this - what I expect I need to do is to find a way to tell my server
> > to accept connections that are destined to its true non-routable
> > address, and also accept connections that are destined to its
> > external, routable address which the firewall makes available to the
> > outside world.
> >
> > I am pulling my hair out trying to understand what I need to do here.
> > Is there some parameter in the cman.ora file which will tell the
> > server to accept such connections? Or am I barking up the wrong tree?
> >
> > Many thanks for all feedback!
> >
> > Cheers,
> >
> > Doug Whittier

Doug,

You can do this without CMAN in 9.2, using shared servers / dispatchers.
you will need to open a minimum of 2 ports on the firewall, one for the listener, one for the dispatcher. Depending upon the number of connections you intend to support in this manner, you may want to balance the load across multiple dispatchers and shared servers. you will need to define explicity the ports for the dispatchers in the init.ora file.
This will get you around the issue of a dedicated session being spawned when a connection is requested, however, it will be a shared server session (virtual circuit) which may introduce a performance bottleneck.

let me know if you require more information.

I was going to put together a paper on this, but once I got the setup working, it went right into production and I couldn't mess with it anymore.

I never did get the default server session type back to dedicated instead of shared. Be aware that is a possible side effect, if your existing tnsnames.ora connect descriptors do not explicitly state SRVR=DEDICATED. Paul Received on Thu Apr 01 2004 - 11:13:16 CST