I have an issue with our listener trying to assign random ports to JDBC connections.

We have a 19c oracle db running on a RHEL server with two ports opened 1523 and 1524. When application tries to connect using JDBC it connects on one of the above ports assigned to listener but then we can see in the log that listener assigns some random port from 30000-65000 range.

...(HOST=`_jdbc_`)(USER=xyz))) * (ADDRESS=(PROTOCOL=tcp)(HOST= * establish * hostname * 0

but the application doesn't receive information about connection as those random ports are not opened.

Any idea how we can set specific ports to be used rather than those random ones?

  • Your analysis is wrong. (HOST= means that the client on host uses port 60579 for the communication. with the server. But this port was not assigned by the listener to him but was assigned by the clients machines operating system when the client opened the communication to the listener.
    – miracle173
    Mar 7, 2022 at 11:44
  • So you should us tell which problem the client actually encounters. Do you get an error message?
    – miracle173
    Mar 7, 2022 at 11:45

2 Answers 2


The port in the log is the port on the client machine, not the port on the server. Client ports are essentially random, in the range you specified, as they are assigned sequentially by the client operating system on demand for outgoing connections. They cannot be set.

For example, running netstat -an from my client after making a database connection reveals the following:

Active Connections

Proto  Local Address          Foreign Address     State

Note that the server port is still 1521, and my client port is in the same high range you specified. Run netstat -an on either your client or database server and you should be able to confirm the actual port numbers in use at each end of the connection.

  • +1 This is basically correct, but if one has a RAC or shared servers configure then the listener asks the client to open a new connection to the database server on a different port than 1521
    – miracle173
    Mar 7, 2022 at 11:57
  • The key here is that the destination port is always fixed and known (default 1521, but could be other), and the client port is always random. The destination port is generally the same across all services, so that modern security/firewall rules can be supported: the client connection is handed off (not reconnected) from one service to another, but the destination port remains the same. Oracle used to force a change in ports, but they dropped that behavior a long time ago because it was incompatible with host and network firewall protections.
    – pmdba
    Mar 7, 2022 at 14:37
  • I am not sure if I understand your comment. What does "the client connection is handed off (not reconnected)" mean?. If your clients connects to a scan listener of a RAC, the scan listener tells the client to which local listener it should connect. This connection to both listeners is written to their log files. The destination port of the connection to the local listener is the port defined for the local listener and not the port of the scan listener. Of course in configuration both ports are 1521. There are no problems with "traditional" firewalls if you configure the correct rules.
    – miracle173
    Mar 8, 2022 at 8:27
  • From the client's perspective (and the firewall) the connection still goes through the SCAN IP and is never broken. The original connection is "handed off" to a different server process (dedicated server, shared server, etc.) on the server side without affecting the TCP connection, so the port number doesn't change. See here: oracle.com/webfolder/technetwork/tutorials/…, docs.oracle.com/en/database/oracle/oracle-database/21/netag/…
    – pmdba
    Mar 8, 2022 at 12:24
  • The Oracle Community thread linked by Ed below also goes into great detail on this: community.oracle.com/tech/developers/discussion/4486985/…
    – pmdba
    Mar 8, 2022 at 12:39

You firewall needs to be configured to allow those random ports when the request is initiated by the server. That's how it works. The port you have configured at the listener is for the exclusive use of the listener itself, to receive connection requests. That port is not used for the ongoing communication between the client and the server process. When the listener confirms that it knows about the requested database, it spawns a server process and tells the client what port to use to communicate with that process. The listener only receives the connection request and sets up the connection. Once that connection is set up, the listener is out of the picture. You can even shut down the listener, and existing connections will be unaffected.

As an aside, why have you assigned two ports to the listener, and why are neither one on the default of 1521? One single listener, with the default name of LISTENER, using the single default port of 1521, is quite capable of -- indeed, was designed to - service multiple databases of multiple versions running from multiple ORACLE_HOMEs.

  • The snippet is from the listener log, which shows client information, not server information. A dedicated server process will continue to use port 1521 (or 1523/1524 in this case) even after the listener hands the connection off, else firewall exceptions would not work.
    – pmdba
    Jul 20, 2021 at 12:25
  • @pmdba - Ah. this raised several questions in my mind, so I ran some tests, and took it up on OTN. Seems what I described used to be the case, but now it's more complex. You can see the discussion at community.oracle.com/tech/developers/discussion/4486985/… Thanks for the corrective lead.
    – EdStevens
    Jul 20, 2021 at 21:50
  • no problem. I read through the discussion. The client-side (source) port is assigned by the client OS when the connection is initiated - it basically just cycles through all the unused high ports in sequence. Any outbound network connection for any program does this. The server (destination) port is fixed to a specific service, like 80 for HTTP or 1521 for TNS. Firewalls key on the destination port for the most part. The source (client) IP address and port will be unique and allow the service to identify individual connections.
    – pmdba
    Jul 20, 2021 at 22:20
  • -1 That is wrong. In database configurations that do not use shared servers or RAC with scan listener the port on database server side will continue to be 1521. A tcp connection is determined by 4 parameters: source ip, source port, target ip, target port. So to (database server, Listener port) every possible (client server, client port) can be communicate at the same time
    – miracle173
    Mar 7, 2022 at 12:10
  • 1
    @miracle173 - as explained in the OTN thread I linked to ... back in July! Kinda curious as to why, almost 8 months later, you even came across this, much less felt a need to add another downvote .... ????
    – EdStevens
    Mar 7, 2022 at 17:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.