Query on UDP proxy socket using freeradius version 3.0.16
I see UDP socket is bind to port 0 which means kernel will allocate the ephemeral port based on the available list. I am observing that the port is still in open state even though after request is served. It's listed in netstat -anp command after 2 days. There is no message served by that port for last 2 days. *netstat -anp* output udp 0 0 0.0.0.0:*26307 *0.0.0.0:* 19293/radiusd Below is *ss -anp* output udp UNCONN 0 0 *:26307 *:* users:(("radiusd",pid=19293,fd=26)) Can anyone help to answer when this socket bind to port 26307 get closed or always in open state ? Problem here if suppose want to connect to 100 different AAAs, then all socket will be in open state which may not correct. Thanks, Saurabha
On Jun 16, 2023, at 8:35 AM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
I see UDP socket is bind to port 0 which means kernel will allocate the ephemeral port based on the available list.
Yes.
I am observing that the port is still in open state even though after request is served. It's listed in netstat -anp command after 2 days. There is no message served by that port for last 2 days.
*netstat -anp* output udp 0 0 0.0.0.0:*26307 *0.0.0.0:* 19293/radiusd
That's weird. This is an OS issue. i.e. FreeRADIUS tells the OS "I'm giving you port 0, so that means _don't_ bind to port 0, but instead to some random high port". The OS should bind the socket to a random high port, and definitely not to port 0.
Below is *ss -anp* output udp UNCONN 0 0 *:26307 *:* users:(("radiusd",pid=19293,fd=26))
Can anyone help to answer when this socket bind to port 26307 get closed or always in open state ? Problem here if suppose want to connect to 100 different AAAs, then all socket will be in open state which may not correct.
That port is used for outbound proxying. If you want to close the port... just stop FreeRADIUS, or disable proxying. There is no problem here. If you run multiple servers on the same machine, "bind to port 0" will work for all of them. The OS will just pick different (and unused) ports for each one. Alan DeKok.
I see freeradius bind to port 0, and then OS takes care of assigning right port, but why freeradius doesn't close the same port programmatically after finish the request? Few more questions, 1. Disable proxy ? How to do that, want to close socket fd w/o restarting freeradius ? 2. Observed sometimes freeradius running as a client, open 2 different proxy ports simultaneously to the same AAA ? When is this possible ? Thanks, Saurabha On Fri, Jun 16, 2023 at 6:15 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jun 16, 2023, at 8:35 AM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
I see UDP socket is bind to port 0 which means kernel will allocate the ephemeral port based on the available list.
Yes.
I am observing that the port is still in open state even though after request is served. It's listed in netstat -anp command after 2 days. There is no message served by that port for last 2 days.
*netstat -anp* output udp 0 0 0.0.0.0:*26307 *0.0.0.0:* 19293/radiusd
That's weird. This is an OS issue.
i.e. FreeRADIUS tells the OS "I'm giving you port 0, so that means _don't_ bind to port 0, but instead to some random high port".
The OS should bind the socket to a random high port, and definitely not to port 0.
Below is *ss -anp* output udp UNCONN 0 0 *:26307 *:* users:(("radiusd",pid=19293,fd=26))
Can anyone help to answer when this socket bind to port 26307 get closed or always in open state ? Problem here if suppose want to connect to 100 different AAAs, then all socket will be in open state which may not correct.
That port is used for outbound proxying. If you want to close the port... just stop FreeRADIUS, or disable proxying.
There is no problem here. If you run multiple servers on the same machine, "bind to port 0" will work for all of them. The OS will just pick different (and unused) ports for each one.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Jun 16, 2023, at 9:08 AM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
I see freeradius bind to port 0, and then OS takes care of assigning right port, but why freeradius doesn't close the same port programmatically after finish the request?
FreeRADIUS never opens a socket to port 0. It opens a socket, and asks the OS to bind it to a port. If the OS leaves port 0 open, then there's nothing that FreeRADIUS can do.
Few more questions, 1. Disable proxy ? How to do that, want to close socket fd w/o restarting freeradius ?
You can disable proxying by updating the configuration files. Look for "proxy" in radiusd.conf.
2. Observed sometimes freeradius running as a client, open 2 different proxy ports simultaneously to the same AAA ? When is this possible ?
It's always possible. It works automatically. You don't have to manually assign proxy ports. That's why FreeRADIUS uses the special port 0. As I said in my previous message, it's a signal to the OS to pick a random unused port. Alan DeKok.
Thanks for your answer. Few more doubts on your answer when freeradius run as client and proxying packet. AAA I refer to the server here. When port change happens at freeradius as client for the same AAA ? If freeradius client say suppose bind to 26001 and authentication happens, then why will it change to another port say suppose 26002 or any other port even though first port (26001) is open and serving. Is this because of high load or any thing as such ? Can all threads use the same AAA port when thousands of messages get served or multiple ports opened at the same time ? Thanks, Saurabha On Fri, Jun 16, 2023 at 7:22 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jun 16, 2023, at 9:08 AM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
I see freeradius bind to port 0, and then OS takes care of assigning
right
port, but why freeradius doesn't close the same port programmatically after finish the request?
FreeRADIUS never opens a socket to port 0. It opens a socket, and asks the OS to bind it to a port.
If the OS leaves port 0 open, then there's nothing that FreeRADIUS can do.
Few more questions, 1. Disable proxy ? How to do that, want to close socket fd w/o restarting freeradius ?
You can disable proxying by updating the configuration files. Look for "proxy" in radiusd.conf.
2. Observed sometimes freeradius running as a client, open 2 different proxy ports simultaneously to the same AAA ? When is this possible ?
It's always possible. It works automatically. You don't have to manually assign proxy ports.
That's why FreeRADIUS uses the special port 0. As I said in my previous message, it's a signal to the OS to pick a random unused port.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Jun 16, 2023, at 10:34 AM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
Thanks for your answer. Few more doubts on your answer when freeradius run as client and proxying packet. AAA I refer to the server here.
Most of your concerns are dealing with basic Unix operation, not with FreeRADIUS.
When port change happens at freeradius as client for the same AAA ? If freeradius client say suppose bind to 26001 and authentication happens, then why will it change to another port say suppose 26002 or any other port even though first port (26001) is open and serving. Is this because of high load or any thing as such ?
I don't understand the question. I think you're confused about a bunch of things, and can't explain things clearly. Both a RADIUS client and server can run on the same machine at the same time. It's fine. If you want to know why, you can read a book on "Unix networking 101". All of this is explained extensively in various documentation about networking. i.e. none of this has anything to do with RADIUS or FreeRADIUS.
Can all threads use the same AAA port when thousands of messages get served or multiple ports opened at the same time ?
You can read the source code. In general, you don't need to know this information. If you're modifying the source code, then go read the source code. If you're just administering a RADIUS server, then you don't need to know the details. It works, it's fine. If you still care about the details, even though you're just running the server, then you can go read the source code. It's not productive for me to explain all of the internal implementation details and design. This list isn't a place to learn about Unix networking. That information is documented extensively elsewhere on the net. Alan DeKok.
Hi, Sorry i may missed to present the problem to you. I am a user of freeradius last 10 years since 2.0.12. We deployed freeradius as client which receives radius message from UE/AP and proxy that to external AAA for auth and acct. You think it's 100 messages per second. Facing one customer issue where even though udp socket is open and serving request to a AAA on a source port, observed a new port is open to same AAA. My doubt is why a new socket with a new port to same AAA even if there is a one already. This behavior seen sometime not always. Thanks, Saurabha On Fri, 16 Jun 2023, 20:13 Alan DeKok, <aland@deployingradius.com> wrote:
On Jun 16, 2023, at 10:34 AM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
Thanks for your answer. Few more doubts on your answer when freeradius
run
as client and proxying packet. AAA I refer to the server here.
Most of your concerns are dealing with basic Unix operation, not with FreeRADIUS.
When port change happens at freeradius as client for the same AAA ? If freeradius client say suppose bind to 26001 and authentication happens, then why will it change to another port say suppose 26002 or any other port even though first port (26001) is open and serving. Is this because of high load or any thing as such ?
I don't understand the question. I think you're confused about a bunch of things, and can't explain things clearly.
Both a RADIUS client and server can run on the same machine at the same time. It's fine. If you want to know why, you can read a book on "Unix networking 101". All of this is explained extensively in various documentation about networking.
i.e. none of this has anything to do with RADIUS or FreeRADIUS.
Can all threads use the same AAA port when thousands of messages get served or multiple ports opened at the same time ?
You can read the source code.
In general, you don't need to know this information. If you're modifying the source code, then go read the source code.
If you're just administering a RADIUS server, then you don't need to know the details. It works, it's fine.
If you still care about the details, even though you're just running the server, then you can go read the source code. It's not productive for me to explain all of the internal implementation details and design.
This list isn't a place to learn about Unix networking. That information is documented extensively elsewhere on the net.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Jun 16, 2023, at 12:08 PM, Saurabh <saurabh24sbp@gmail.com> wrote:
We deployed freeradius as client which receives radius message from UE/AP and proxy that to external AAA for auth and acct. You think it's 100 messages per second.
That's fine.
Facing one customer issue where even though udp socket is open and serving request to a AAA on a source port, observed a new port is open to same AAA.
Is that causing a problem?
My doubt is why a new socket with a new port to same AAA even if there is a one already. This behavior seen sometime not always.
Why not just say that at the start, instead of asking a bunch of unrelated questions? This is how RADIUS works. It's fine. i.e. If it's working, don't waste your time worrying about it. Do the log messages contain an error? No? Then it's fine. Why worry when there's no error? Alan DeKok.
Yes customer deployed load balancer based on the source port map to specific AAA server, Observed source port change for an ongoing authentication session, access-request is initiated from a different port after few access-challenges causing the load balancer to send the request to a different AAA and then get rejected. Is this behavior proper and expected, source port change for an ongoing authentication session ? On Fri, Jun 16, 2023 at 9:58 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jun 16, 2023, at 12:08 PM, Saurabh <saurabh24sbp@gmail.com> wrote:
We deployed freeradius as client which receives radius message from UE/AP and proxy that to external AAA for auth and acct. You think it's 100 messages per second.
That's fine.
Facing one customer issue where even though udp socket is open and serving request to a AAA on a source port, observed a new port is open to same AAA.
Is that causing a problem?
My doubt is why a new socket with a new port to same AAA even if there is a one already. This behavior seen sometime not always.
Why not just say that at the start, instead of asking a bunch of unrelated questions?
This is how RADIUS works. It's fine.
i.e. If it's working, don't waste your time worrying about it.
Do the log messages contain an error?
No? Then it's fine. Why worry when there's no error?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Jun 16, 2023, at 12:58 PM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
Yes customer deployed load balancer based on the source port map to specific AAA server,
So you're asking if someone else's load balancer is working properly? This isn't a FreeRADIUS issue.
Observed source port change for an ongoing authentication session, access-request is initiated from a different port after few access-challenges causing the load balancer to send the request to a different AAA and then get rejected.
Is this behavior proper and expected, source port change for an ongoing authentication session ?
It's allowed by the specifications. And again... why not ask this question *first*? Why spend all kinds of time asking useless and irrelevant questions? That is not productive. Alan DeKok.
It's like freeradius <-> loadbalancer <-> AAA Based on proxy udp src port load balancer map the request to a AAA, so if a src port is mapped to AAA1 for few initial access request and access-challenge before accept, if next request get proxied with a new src port then load balancer sends to a different AAA, may be AAA2 which reject it. Because of freeradius udp port change request get rejected. That's why I asked this query ita related to freeradius. Thanks, Saurabha On Fri, 16 Jun 2023, 22:39 Alan DeKok, <aland@deployingradius.com> wrote:
On Jun 16, 2023, at 12:58 PM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
Yes customer deployed load balancer based on the source port map to specific AAA server,
So you're asking if someone else's load balancer is working properly?
This isn't a FreeRADIUS issue.
Observed source port change for an ongoing authentication session, access-request is initiated from a different port after few access-challenges causing the load balancer to send the request to a different AAA and then get rejected.
Is this behavior proper and expected, source port change for an ongoing authentication session ?
It's allowed by the specifications.
And again... why not ask this question *first*? Why spend all kinds of time asking useless and irrelevant questions? That is not productive.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 16/06/2023 18:40, saurabha badhai wrote:
Based on proxy udp src port load balancer map the request to a AAA, so if a src port is mapped to AAA1 for few initial access request and access-challenge before accept, if next request get proxied with a new src port then load balancer sends to a different AAA, may be AAA2 which reject it.
That's a crazy way to do it based on false assumptions. You want to determine the destination location by looking at an ephemeral source port. Some basic thoughts about this should start to ring alarm bells. If you've really got to NAT stuff, use a block of IPs and get FreeRADIUS to send to an individual IP per customer, and NAT based on that. Or use one IP and configure FreeRADIUS to connect to a different port per customer, and NAT based on *destination* port. Doing what you are doing is asking for trouble, which is exactly what you've got.
Because of freeradius udp port change request get rejected.
That's why I asked this query ita related to freeradius.
No, it's broken assumptions because of not understanding the way networking works. -- Matthew
On Jun 16, 2023, at 1:40 PM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
freeradius <-> loadbalancer <-> AAA
That doesn't make much sense. But at this point, I'm not surprised. Every message has new / different information. Which means it's very difficult to help you.
Based on proxy udp src port load balancer map the request to a AAA, so if a src port is mapped to AAA1 for few initial access request and access-challenge before accept, if next request get proxied with a new src port then load balancer sends to a different AAA, may be AAA2 which reject it.
The load balancer is broken. It doesn't do RADIUS properly.
Because of freeradius udp port change request get rejected.
No. The request gets rejected for a different reason. The reason is in the FreeRADIUS logs.
That's why I asked this query ita related to freeradius.
So you didn't describe what is *actually* happening until about 5 messages in. The previous messages all asked unrelated / irrelevant questions which were unrelated to the actual issue. And when FreeRADUS rejects the request, it gives the reason. All of this nonsense could have been avoided if you had (a) posted the debug log as suggested by ALL OF THE DOCUMENTATION and (b) given a clear description of the problem in the first message. Instead, you put a lot of effort into doing things which are completely useless. This isn't a FreeRADIUS problem. The load balancer is broken. If you're going to continue asking questions, then you need to post questions *only* about FreeRADIUS, and also *include the debug output* as suggested by all of the documentation. Alan DeKok.
Thanks to all for answering my questions. I found the information after going through the source code. Will post query with details if any doubt. Thanks, Saurabha On Sat, Jun 17, 2023 at 12:14 AM Alan DeKok <aland@deployingradius.com> wrote:
On Jun 16, 2023, at 1:40 PM, saurabha badhai <saurabha.badhai@gmail.com> wrote:
freeradius <-> loadbalancer <-> AAA
That doesn't make much sense. But at this point, I'm not surprised. Every message has new / different information. Which means it's very difficult to help you.
Based on proxy udp src port load balancer map the request to a AAA, so if a src port is mapped to AAA1 for few initial access request and access-challenge before accept, if next request get proxied with a new src port then load balancer sends to a different AAA, may be AAA2 which reject it.
The load balancer is broken. It doesn't do RADIUS properly.
Because of freeradius udp port change request get rejected.
No.
The request gets rejected for a different reason. The reason is in the FreeRADIUS logs.
That's why I asked this query ita related to freeradius.
So you didn't describe what is *actually* happening until about 5 messages in. The previous messages all asked unrelated / irrelevant questions which were unrelated to the actual issue.
And when FreeRADUS rejects the request, it gives the reason.
All of this nonsense could have been avoided if you had (a) posted the debug log as suggested by ALL OF THE DOCUMENTATION and (b) given a clear description of the problem in the first message.
Instead, you put a lot of effort into doing things which are completely useless.
This isn't a FreeRADIUS problem. The load balancer is broken.
If you're going to continue asking questions, then you need to post questions *only* about FreeRADIUS, and also *include the debug output* as suggested by all of the documentation.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (4)
-
Alan DeKok -
Matthew Newton -
Saurabh -
saurabha badhai