Port number is changing dynamically for each Auth request in RHEL

[ghvijayakumar]

Hello There,
I have a strange issue in RHEL.

Machine name: Linux 10.10.51.129 2.6.18-194.17.1.el5 #1 SMP Mon Sep 20 07:12:06 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

OS name: Description: Red Hat Enterprise Linux Server release 5.5 (Tikanga)

I have installed an application in RHEL machine written in java language used to send authentication request using Radius protocol. The authentication request will hit in a AAA server (AAA stands for Authentication, Authorization and Accounting) where the authentication request being accepted are rejected based on the user credentials (ie., user id and password) available in the AAA server.

Whenever i started sending an authentication request from the RHEL machine to the AAA server, The request is being sent from a different port number. I mean, the port number is changing dynamically for each auth request. But this is not the expected behavior. The request from the RHEL machine should send from a single port number. ie., for all the auth request being send from the RHEL machine should use the SAME port number at all.

Earlier, We installed this application in an older RHEL machine. The machine details are below.

Machine name: Linux 2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686 i386 GNU/Linux
OS version: RHEL ES release 3.0
Kernal version: Kernel Version: 2.4.21-4.EL

In the above configured machine, The authentication request sent from the same port number. I mean, the request is departing from the same port number at all.

But when I send request from latest RHEL machine, the port number is changing dynamically for each request.

Do you have any workaround to fix this issue? or anything to do to fix the outbound port number.

[alf55]

The port used by the client should not matter. The server listens on a standard port and usually switches to another port (like transferring an office phone to an extension so the main number is not tied up) which is returned to the client to what ever port that it was sent from.

Actually most clients will add a random value to some possible port so that when more than one copy is running, the change of getting an unused connection rather than the port is already in use by another and then having to attempt to use another port.

[ghvijayakumar]

In the application, If the authentication request is accepted successfully by the AAA server, If i again start sending the auth request, the application should drop the request without sending it to the AAA server by marking as duplicate request. The duplicate request is identified by the application using the request's source IP+source port. If the port is changing for every request, the application is not marking as duplicate request thus it hits AAA server everytime making AAA overloaded by so many requests.

If the source port is fixed, First time the application will send request to AAA server and gets authenticated. Second request will be dropped by the application itself by checking the source port is same as earlier request.

This is the reason for asking the source port should be unchanged.

[voidpointer69]

gh...

As mentioned above, the Server side is usually the one that requires a consistent port number since the clients need to be able to contact it.

I have written servers that do not require a fixed port but, in such cases, a mechanism was present that allowed the server to advertise the port it was using.

Behind the scenes, what happens when you open up a socket is that you have two basic choices. Specify which port you want to open or let the OS assign you one.

Seems your client is choosing the latter option.

If it needs to track whether or not it has already sent a request, clearly you should not involve the port number that was used before unless you can configure it to use the same one for every request.

Hope this makes sense.

Cheers - VP

[jimseg]

The problem lies with the source of the requests which, from your description, come to your application and then result in a request to the Radius server. If you need to filter out duplicates in your application before sending them to the Radius server, then the source of the application must ensure that it either:

creates a socket for sending a request to your application and keeps it open until it's been authenticated or denied - the source port of requests to your application will not change

or

choose an ephemeral port for its requests and bind the socket to that port before sending the request. As long as a given request always binds to the same port number, the requests will always have the same source port.

But it sounds like there is a design issue or two here:

1) Radius servers should handle a large number of requests, including duplicates without becoming overloaded. I would expect to be able to handle 50 to 100 requests/second without problems on a Radius server, if the anticipated load is higher than that, then use multiple Radius servers and have the clients choose a server at random from that list.

2) the source of the requests should have a timeout for replies which reflects the overall performance of the client->app->Radius->app->client flow of messages. The request should not be re-sent until this timeout has expired. You could use something like tcpdump or snoop to see what the actual response times are for each of the above steps in the protocol to identify what the timeout should be or where unreasonable delays are occurring.

[ghvijayakumar]

The application allows OS to choose the port for sending auth requests. The OS is choosing different port for each auth request. Moreover we have configured the destination port (for auth request it is 11812). But we don't have any configuration to set the source port number.

Though the Radius server handles large number of requests, when the same request is duplicated, the Radius server will overloaded when the duplication increases in number.

The machine
Machine name: Linux 2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686 i386 GNU/Linux
OS version: RHEL ES release 3.0
Kernal version: Kernel Version: 2.4.21-4.EL

chooses the same source port for all auth request. Why this is not the case in the new RHEL machine?? Can we do any workaround in OS side(RHEL) to fix the source port?

[Irithori]

There is nothing to fix on the source side.
Arbitrary source ports are perfectly normal behaviour for about any client on any OS.
Hence I would suggest to modify your application.

[jimseg]

I find your description of your problem to be difficult to follow - if the Radius requests originate from your application, then you must change your application to either open a socket and keep it open until the request is completed and won't be reissued (in which case the port chosen will be an ephemeral port, but will be consistent for the particular request) or you need to change your application so that it binds the source port when it creates a socket to send a request. This will allow you to always use the same port when sending requests.

This is the part that I can't understand in your original posting:

In the application, If the authentication request is accepted successfully by the AAA server, If i again start sending the auth request, the application should drop the request without sending it to the AAA server by marking as duplicate request. The duplicate request is identified by the application using the request's source IP+source port. If the port is changing for every request, the application is not marking as duplicate request thus it hits AAA server everytime making AAA overloaded by so many requests.

First you talk of the application sending the request to the Radius server, then you talk about the application checking the source port of the Radius request. This doesn't make sense to me unless you have a remote client connecting to your application which sends some message prompting your application to make a Radius request. If your application is the one making the Radius requests, then your application should be the point where you drop duplicate requests.

I'd suggest you make an effort to better describe the architecture of your problem.