RE: Radclient receives response messages from different source port than destination port of request messages
Hi Alan, I would like to specify that I'm using radclient as a RADIUS proxy. I reach the RADIUS server through a load balancer. The server uses ports other than 1812 and 1813 in its responses because the matching between requests and responses is done through the Proxy-State attribute. This behavior is implemented in a very famous European Telco operator. In radclient is not implemented any mechanism to support this behavior? Can you confirm that the current implementation of radclient, realizes the matching between requests and responses using also the source port of the responses? Thanks, Rosario -----Original Message----- From: freeradius-users-bounces+rosario.mattera=accenture.com@lists.freeradius.org [mailto:freeradius-users-bounces+rosario.mattera=accenture.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: martedì 28 maggio 2013 18:12 To: FreeRadius users mailing list Subject: Re: Radclient receives response messages from different source port than destination port of request messages rosario.mattera@accenture.com wrote:
Thanks Alan for your response. Anyway I can't modify RADIUS server configuration because does not belongs to my domain.
Then tell the other RADIUS server to fix his system.
The domain administrator told me that RADIUS server responds using a different source port because of Proxy-State attribute is used in the Access-Request.
Nonsense. RADIUS doesn't work like that.
Is there a way to force "radclient" to recognize that response? I have to edit the source files?
No. RADIUS doesn't work like that. FreeRADIUS will *never* work like that. It's stupid, broken, and completely wrong. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com
On 30 May 2013, at 05:23, rosario.mattera@accenture.com wrote:
Hi Alan,
I would like to specify that I'm using radclient as a RADIUS proxy.
Um. Why?
I reach the RADIUS server through a load balancer. The server uses ports other than 1812 and 1813 in its responses because the matching between requests and responses is done through the Proxy-State attribute. This behavior is implemented in a very famous European Telco operator.
This behaviour is wrong and not standards compliant. No where in RFC 2865 or any more recent RADIUS RFCs does it describe a method of tying requests and responses using Proxy-State.
In radclient is not implemented any mechanism to support this behavior?
No.
Can you confirm that the current implementation of radclient, realizes the matching between requests and responses using also the source port of the responses?
Yes. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Thanks for your answer, Arran. Regards, Rosario -----Original Message----- From: freeradius-users-bounces+rosario.mattera=accenture.com@lists.freeradius.org [mailto:freeradius-users-bounces+rosario.mattera=accenture.com@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: giovedì 30 maggio 2013 14:27 To: FreeRadius users mailing list Subject: Re: Radclient receives response messages from different source port than destination port of request messages On 30 May 2013, at 05:23, rosario.mattera@accenture.com wrote:
Hi Alan,
I would like to specify that I'm using radclient as a RADIUS proxy.
Um. Why?
I reach the RADIUS server through a load balancer. The server uses ports other than 1812 and 1813 in its responses because the matching between requests and responses is done through the Proxy-State attribute. This behavior is implemented in a very famous European Telco operator.
This behaviour is wrong and not standards compliant. No where in RFC 2865 or any more recent RADIUS RFCs does it describe a method of tying requests and responses using Proxy-State.
In radclient is not implemented any mechanism to support this behavior?
No.
Can you confirm that the current implementation of radclient, realizes the matching between requests and responses using also the source port of the responses?
Yes. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com
rosario.mattera@accenture.com wrote:
I would like to specify that I'm using radclient as a RADIUS proxy.
Nonsense. radclient is a client. It's not a server. It's not a proxy.
I reach the RADIUS server through a load balancer.
That's fine.
The server uses ports other than 1812 and 1813 in its responses because the matching between requests and responses is done through the Proxy-State attribute.
Then it's not a RADIUS server. RADIUS servers don't work like that.
This behavior is implemented in a very famous European Telco operator.
That behavior is wrong. Maybe they wanted to do something special with their systems. That's fine. But they way they did it shows that they have no idea how RADIUS works.
In radclient is not implemented any mechanism to support this behavior?
No.
Can you confirm that the current implementation of radclient, realizes the matching between requests and responses using also the source port of the responses?
radclient follows the RADIUS standards. It matches requests and responses via src/dst IP/port. Doing anything else is broken. It sounds like whoever built the "very famous European Telco operator" network had no idea how RADIUS works. Rather than doing something simple (and widely used, and widely tested), they resorted to custom solutions which are not maintainable. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
rosario.mattera＠accenture.com