Port Redirection
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:
After the client contact the listener this fork a process and handle the connection which switches on another port.
Corollary:
The firewall needs to allow connection on the listener port and on any other “redirected port”.
My point:
The listener fork the process but the communication (server-side) remains on the listening port and it is not “redirected”. This is true for Dedicated Server and Shared Server connections.
Corollary:
On the firewall only the listening port of the listener needs to be open.
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 address, 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 behavior 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)
orasuse:~ # netstat -an|grep “192.168.24.21”
tcp 0 0 192.168.25.189:1521 192.168.24.21:59271
ESTABLISHED
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
192.168.25.92 is breobsbsls01