This paper collects some discussions I had on newsgroup and mailing list on oracle and the so called "port redirection".
It is intended to help ending the oracle myth regarding the use of oracle (on unix) and firewalls.

The tests have been performed on Linux, AIX, Solaris.
At the moment I haven't got any other unix-like operating system where to expand these test.

First of all the myth:

Corollary:

My point:

Corollary:

On unix there are several tool that can be used to prove it.
The best one, in my opinion, is lsof.
Others can be: netstat, tcpdump, ethereal, etc.

How to prove it:

Take two different machine: client and server (ok, the client can be on the server but it can make the test a little bit more confused while I prefer to simplify).
Open a connection from client to server.
Check, by looking at the IP adress, which ports are being used by the server.

Below you can see the test.
But why oracle doesn't need to redirect the server port?
On TCP a connection is defined by four numbers:  client address, client port, server address, server port.
Two different connection needs to differ at list in one of this numbers.So, if the client open on the same server more then one connection the changing number can be: client port, server port. Changing the client port is enough so you are going to see several connection from the client starting all from a different port.
This happens even for other application like ssh, telnet, ftp, etc. And it is a normal behaviour for a daemon on unix.

From a discussion on google:

Server is a suse linux enterprise edition 7 mounting one node of a RAC
cluster (9.2.0.4). Ip is 192.168.25.189.

I connect from client to server and traced from oracle while taking
information with unix commands.

Here the results:

orasuse:~ # lsof -i -n |grep "192.168.24.21"
sshd      17263   root    5u  IPv6 3447859       TCP
192.168.25.189:ssh->192.168.24.21:59270 (ESTABLISHED)
oracle    17357 oracle   11u  IPv4 3448080       TCP
192.168.25.189:ncube-lm->192.168.24.21:59271 (ESTABLISHED)

orasuse:~ # grep "ncube-lm" /etc/services
ncube-lm        1521/tcp                        # nCube License Manager
ncube-lm        1521/udp                        # nCube License Manager

orasuse:~ # ps -fe|grep 17357
oracle   17357     1  0 20:15 ?        00:00:00 oracleTESTRAC1 (LOCAL=NO)

And this from a discussion about ssh tunneling and shared servers:
 

Just a test:

two machine:
bremosdbls02  (client side)
breobsbsls01  (server side)

One DB: RMAN10G

one listener, listening on PORT 1529
default dispatcher for 10g.

tunneling opened with:

nohup ssh -f -g -L 1530:breobsbsls01.ras:1529 oracle...@breobsbsls01.ras
ping -i 100 breobsbsls01.ras

from bremosdbls02  (user oracle)

I connect via sqlplus to local port 1530 using the shared server

RMAN10G =
   (DESCRIPTION =
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = bremosdbls02.ras)(PORT = 1530))
     (CONNECT_DATA =
       (SERVICE_NAME = RMAN10GXDB)
       (SERVER=shared)
     )
   )

and check what happens via tcpdump (none but me is connected at the DB):

sqlplus system/rman_10g_@rman10g

SQL*Plus: Release 10.2.0.1.0 - Production on Fri Aug 26 11:37:08 2005

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Production
With the Partitioning and Data Mining options

SQL> select * from v$circuit;

CIRCUIT  DISPATCH SERVER   WAITER   SADDR    STATUS           QUEUE
-------- -------- -------- -------- -------- ----------------
----------------
   MESSAGE0   MESSAGE1   MESSAGE2   MESSAGE3   MESSAGES      BYTES
BREAKS
---------- ---------- ---------- ---------- ---------- ---------- ----------
PRESENTATION
--------------------------------------------------------------------------------
PCIRCUIT
--------
599FC18C 5AC6E140 5AC6E650 00       5AD46828 NORMAL           SERVER
          0          1          0          0         33       5066
     0
TTC
00

ps -fe|grep sqlplus
oracle   16427 27367  0 11:41 pts/1    00:00:00 sqlplus
root     16791 14492  0 11:43 pts/3    00:00:00 grep sqlplus
You have new mail in /var/mail/root
bremosdbls02:~ # lsof -p 16427|grep ESTAB
sqlplus 16427 oracle    8u  IPv4 4717301              TCP
bremosdbls02.ras:32987->bremosdbls02.ras:rap-service (ESTABLISHED)
bremosdbls02:~ # grep rap-service /etc/services
rap-service     1530/tcp    # rap-service
rap-service     1530/udp    # rap-service

Client side the connection is kept on the 1530.

While on server side it is still on 1529:

lsof -p 20664|grep ESTAB
oracle  20664 oracle10g   15u  IPv4  339804982                TCP
breobsbsls01.ras:coauthor->breobsbsls01.ras:8647 (ESTABLISHED)
oracle10g@breobsbsls01:~> grep coauthor /etc/services
coauthor        1529/tcp        # oracle
coauthor        1529/udp        # oracle

Contact information:
fabrizio.magni _at_ gmail.com