There are two sqlnet (sqlnet1 and sqlnet2) services that come already
configured in Firewall 1. Sqlnet 1 is just like most of the other services,
it just references a port number. Sqlnet 2 has some code behind it that I
assume is designed to grab that assigned port out of the data and allow
subsequent traffic thru. I have been told that it is not totally reliable.
For me, it was easy just to use the single threaded model and not have to
deal with the other so I never even tried it.
Hope this helps.
Jim Edwards
-----Original Message-----
From: fwmlist owner [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 19, 2000 10:06 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: RE: [FW1] Oracle Web Application
Hi,
If the database is really configured as multithread mode, any pointers on
the firewall rules configuration since it
will be communicating with high port range?
Thanks and regards,
AC
On Wed, 14 Jun 2000 16:09:53 -0500, James Edwards <[EMAIL PROTECTED]>
wrote:
> I have dealt with this myself more than once. This is actually what is
> called an sqlnet2 connection in the firewall and I have been told it
doesn't
> work
>
> Here is what happens:
>
> First, the database is in multi-threaded mode. In single thread mode, the
> server opens a separate login process for each connection and that user
(and
> every other user) communicates to the server on port 1521 for the duration
> of the session and all the different users are identified by their user
id.
> So, the firewall sees port 1521 and everything is fine. The drawback to
> this method is all those user processes hogging up resources.
>
> Now, in multithreaded mode, the client connects on 1521 or 1526 and then
is
> assigned a high port to use for the duration of the connection. If you
> snoop it you see several packets on 1525 then it starts back up on a
higher
> one. The server identifies each connection/user by what port they come in
> on and doesn't have to create a new process, thereby supposedly saving
> resources. The kicker here is that this port assignment is buried in the
> data portion of the packet and as such is not identifiable by the
firewall.
> I was told by Oracle that unless you have a large number of users
connecting
> directly to the database, this method is actually worse than the single
> threaded method.
>
> For a app server to database server connection, which is a lot of very
fast
> connect and drops, I would definitely use the single threaded model.
Check
> your init.ora file on the database server for any parameters starting with
> "mts". Comment them out and bounce the database. You can always put them
> back if you run into performance problems.
>
> Hope this helps.
>
>
> Jim Edwards
> Systems Manager
> Texas Secretary of State
>
>
> -----Original Message-----
> From: Kelly, John [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 14, 2000 2:04 PM
> To: [EMAIL PROTECTED]
> Subject: [FW1] Oracle Web Application
>
>
>
> My client just installed an Oracle web application on a web server in the
> DMZ. The web server needs to connect to the Oracle DB server on the
internal
> network. The developer said that the app will communicate on ports 1521
and
> 1526. I added the rule to allow the connection with those ports specified
as
> the service. The app cannot connect. The log on the FW-1 shows the initial
> connection on 1521, however the app also tries to open a connection on a
> random port in the 1850 range which is dropped. About a minute later the
> 1526 port opens but the app still fails. Anyone dealt with this before? I
> have him checking into why the app uses three ports; 1521, 1526 and an
1850
> something but was hoping one of you have dealt with this and can point me
in
> the right direction. thanks!
>
> John
>
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
