sqlippool and exhausted pool
Hello, because of the IPv4 shortage we exhausted our PPPOE assignment public IP address pool, I could not find documentation on this: what happens if pool is full and an AAA request arrives to the radius? At the moment it seems we have cases of users having a public IP address and actually accessing internet with that BUT in the pool table it is not correcty taken, so this generate cases where 2 different users have the same IP address, only one working. Thanks for the help! -- Mirko Alberio Amministratore di Sistemi Via Enrico Fermi, 235 - 36100 Vicenza - Italia Tel 0444 291302 - Fax 0444 566310 - www.telemar.it <http://www.telemar.it> Reg. Imp. Di Vicenza /C.F./P.I. 02508710247 Cap. Soc. € 120.000,00 I.V. R.E.A. VI-236292 <https://it-it.facebook.com/TelemarIt/> <https://www.instagram.com/telemar_it/> <https://it.linkedin.com/company/telemar-s-p-a-> Il presente messaggio non costituisce offerta e/o accettazione contrattuale. Ai sensi del Regolamento europeo per la protezione dei dati personali n. 679/2016 (GDPR) si precisa che le informazioni contenute in questo messaggio e/o nel/i file/s allegato/i sono riservate ed a uso esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo e a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. Pursuant to General Data Protection Regulation (GDPR), you are hereby informed that this message contains confidential information intended only for the use of the addressee. If you are not the addressee, and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
On Jul 19, 2021, at 3:19 AM, Alberio Mirko via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
because of the IPv4 shortage we exhausted our PPPOE assignment public IP address pool,
I could not find documentation on this: what happens if pool is full and an AAA request arrives to the radius?
The module returns FAIL if it can't assign an IP address. What happens after that depends on your local configuration
At the moment it seems we have cases of users having a public IP address
Which comes from where?
and actually accessing internet with that BUT in the pool table it is not correcty taken, so this generate cases where 2 different users have the same IP address, only one working.
The server doesn't randomly assign IP addresses. It only assigns IP addresses when you tell it to assign IP addresses. The IP pool module doesn't assign the same IP to two different users. It relies on the database to track usage. Now, if the NAS lies to FreeRADIUS about who is online, then anything can happen. But you can't blame FreeRADIUS for that. Alan DeKok.
Hi Alan, thanks for the answer, I have some doubts: The module returns FAIL if it can't assign an IP address. What happens after that depends on your local configuration What do you mean with "depends on your local configuration"? Which comes from where? That is the point: the customer takes an IP from the pool without allocating the pool. Maybe is something related to the above question? Meaning is there something I miss to "block" a user on sqlippool module FAIL? And another thing I noticed: we have some expiry_time way back in the past, but the ip is correctly assigned in NAS: What could it be? thanks! Mirko Alberio Amministratore di Sistemi Via Enrico Fermi, 235 - 36100 Vicenza - Italia Tel 0444 291302 - Fax 0444 566310 - www.telemar.it <http://www.telemar.it> Reg. Imp. Di Vicenza /C.F./P.I. 02508710247 Cap. Soc. € 120.000,00 I.V. R.E.A. VI-236292 <https://it-it.facebook.com/TelemarIt/> <https://www.instagram.com/telemar_it/> <https://it.linkedin.com/company/telemar-s-p-a-> Il presente messaggio non costituisce offerta e/o accettazione contrattuale. Ai sensi del Regolamento europeo per la protezione dei dati personali n. 679/2016 (GDPR) si precisa che le informazioni contenute in questo messaggio e/o nel/i file/s allegato/i sono riservate ed a uso esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo e a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. Pursuant to General Data Protection Regulation (GDPR), you are hereby informed that this message contains confidential information intended only for the use of the addressee. If you are not the addressee, and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you. Il 19/07/2021 14:08, Alan DeKok ha scritto:
On Jul 19, 2021, at 3:19 AM, Alberio Mirko via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
because of the IPv4 shortage we exhausted our PPPOE assignment public IP address pool,
I could not find documentation on this: what happens if pool is full and an AAA request arrives to the radius? The module returns FAIL if it can't assign an IP address.
What happens after that depends on your local configuration
At the moment it seems we have cases of users having a public IP address Which comes from where?
and actually accessing internet with that BUT in the pool table it is not correcty taken, so this generate cases where 2 different users have the same IP address, only one working. The server doesn't randomly assign IP addresses. It only assigns IP addresses when you tell it to assign IP addresses.
The IP pool module doesn't assign the same IP to two different users. It relies on the database to track usage.
Now, if the NAS lies to FreeRADIUS about who is online, then anything can happen. But you can't blame FreeRADIUS for that.
Alan DeKok.
On Jul 19, 2021, at 8:55 AM, Alberio Mirko <mirko.alberio@telemar.it> wrote:
Hi Alan, thanks for the answer, I have some doubts:
The module returns FAIL if it can't assign an IP address.
What happens after that depends on your local configuration
What do you mean with "depends on your local configuration"?
The module just returns "fail". Then, the virtual server gets processed as normal. This means any additional unlang rules, or modules, or... i.e. whatever is in the virtual server. Which is your local configuration.
Which comes from where? That is the point: the customer takes an IP from the pool without allocating the pool. Maybe is something related to the above question? Meaning is there something I miss to "block" a user on sqlippool module FAIL?
No. If the module returns "fail", then it hasn't assigned an IP. Something else is going on. Either the NAS is assigning an IP, or something else is assigning an IP. You need to track down what's going on. Perhaps by checking debug output...
And another thing I noticed:
<pgdabjemfidclimd.png>
we have some expiry_time way back in the past, but the ip is correctly assigned in NAS:
The IP is in use by the NAS. It is not CORRECTLY assigned in the NAS.
<djjikgpmfhkndkah.png>
What could it be?
Your NAS is broken. If the DB says that the IP is expired, then FreeRADIUS thinks that the IP has expired. And can therefore assign it again. However, if the IP is still in use by the NAS, then assigning the IP to another system will cause problems. The NAS SHOULD be sending accounting packets which indicate that the session is still in use, and that the IP is still allocated. If those packets are sent, then FreeRADIUS will update the DB to say that the IP is still in use. So what's happening here one of two things: 1) your NAS isn't sending accounting update messages 2) you've configured FreeRADIUS to not run the sqlippool module when it receives accounting update messages. (1) is much more likely than (2). Fix the NAS, and the problem will go away. Alan DeKok.
Ok, thanks: investigating in the NAS: i tried debugging that user with IP 185.138.36.176 that has expiry_time on 2021-01-15 20:12:31 I tried disconnecting his PPPOE session, shortly afterward I get this request in the freeradius/radacct/NASIPADDRESS/ log files Mon Jul 19 15:25:35 2021 Packet-Type = Access-Request Service-Type = Framed-User Framed-Protocol = PPP NAS-Port = 15923828 NAS-Port-Type = Ethernet User-Name = "xxxxxxxxx" Calling-Station-Id = "50:0F:F5:D9:86:80" Called-Station-Id = "vlan101" NAS-Port-Id = "vlan101-zzzzzz" NAS-Identifier = "yyyy" NAS-IP-Address = 10.255.255.85 Timestamp = 1626701135 And the authentication is fine. But still the expiry_time isn't updated. I should se another Accounting request below that right? Mirko Alberio Amministratore di Sistemi Via Enrico Fermi, 235 - 36100 Vicenza - Italia Tel 0444 291302 - Fax 0444 566310 - www.telemar.it <http://www.telemar.it> Reg. Imp. Di Vicenza /C.F./P.I. 02508710247 Cap. Soc. € 120.000,00 I.V. R.E.A. VI-236292 <https://it-it.facebook.com/TelemarIt/> <https://www.instagram.com/telemar_it/> <https://it.linkedin.com/company/telemar-s-p-a-> Il presente messaggio non costituisce offerta e/o accettazione contrattuale. Ai sensi del Regolamento europeo per la protezione dei dati personali n. 679/2016 (GDPR) si precisa che le informazioni contenute in questo messaggio e/o nel/i file/s allegato/i sono riservate ed a uso esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo e a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. Pursuant to General Data Protection Regulation (GDPR), you are hereby informed that this message contains confidential information intended only for the use of the addressee. If you are not the addressee, and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you. Il 19/07/2021 15:04, Alan DeKok ha scritto:
On Jul 19, 2021, at 8:55 AM, Alberio Mirko <mirko.alberio@telemar.it> wrote:
Hi Alan, thanks for the answer, I have some doubts:
The module returns FAIL if it can't assign an IP address.
What happens after that depends on your local configuration
What do you mean with "depends on your local configuration"? The module just returns "fail". Then, the virtual server gets processed as normal. This means any additional unlang rules, or modules, or...
i.e. whatever is in the virtual server. Which is your local configuration.
Which comes from where? That is the point: the customer takes an IP from the pool without allocating the pool. Maybe is something related to the above question? Meaning is there something I miss to "block" a user on sqlippool module FAIL? No. If the module returns "fail", then it hasn't assigned an IP.
Something else is going on. Either the NAS is assigning an IP, or something else is assigning an IP. You need to track down what's going on. Perhaps by checking debug output...
And another thing I noticed:
<pgdabjemfidclimd.png>
we have some expiry_time way back in the past, but the ip is correctly assigned in NAS: The IP is in use by the NAS. It is not CORRECTLY assigned in the NAS.
<djjikgpmfhkndkah.png>
What could it be? Your NAS is broken.
If the DB says that the IP is expired, then FreeRADIUS thinks that the IP has expired. And can therefore assign it again.
However, if the IP is still in use by the NAS, then assigning the IP to another system will cause problems. The NAS SHOULD be sending accounting packets which indicate that the session is still in use, and that the IP is still allocated. If those packets are sent, then FreeRADIUS will update the DB to say that the IP is still in use.
So what's happening here one of two things:
1) your NAS isn't sending accounting update messages
2) you've configured FreeRADIUS to not run the sqlippool module when it receives accounting update messages.
(1) is much more likely than (2).
Fix the NAS, and the problem will go away.
Alan DeKok.
On Jul 19, 2021, at 9:30 AM, Alberio Mirko <mirko.alberio@telemar.it> wrote:
Ok, thanks: investigating in the NAS: i tried debugging that user with IP 185.138.36.176
that has expiry_time on 2021-01-15 20:12:31
I tried disconnecting his PPPOE session, shortly afterward I get this request in the freeradius/radacct/NASIPADDRESS/ log files
Mon Jul 19 15:25:35 2021 Packet-Type = Access-Request
That doesn't help. You need to look at your local configuration to see what happens with accounting packets, and where they're going. Then, look in the accounting log files. Usually a "detail" file.
And the authentication is fine. But still the expiry_time isn't updated. I should se another Accounting request below that right?
No. Accounting packets get logged to different locations than authentication packets. Alan DeKok.
Ok, thanks, I did some packet capture in the problematic NAS, accounting Stop packet are actually being sent, but still the table is not updated. I attach the capture. So the NAS is sending account data! And another quick question: we noticed also some cases where username deleted from the radcheck and radreply tables (dismissed customers) are still present in the radippool table, with past expiry_time: should not be automatically "pruned"? Those customers for example could disconnect the router cable and the NAS is not able to send the Stop packet. Thanks again. Mirko Alberio - Assistenza tecnica e-mail: mirko.alberio@telemar.it Telemar SpA Internet Quality Provider Via Enrico Fermi, 235 - 36100 Vicenza - Italia Tel 0444 291302 - Fax 0444 566310 - www.telemar.it Assistenza tecnica 0444 1420000 Reg. Imp. Di Vicenza /C.F./P.I. 02508710247 Cap. Soc. € 120.000,00 I.V. R.E.A. VI-236292 Il 19/07/2021 16:21, Alan DeKok ha scritto:
On Jul 19, 2021, at 9:30 AM, Alberio Mirko <mirko.alberio@telemar.it> wrote:
Ok, thanks: investigating in the NAS: i tried debugging that user with IP 185.138.36.176
that has expiry_time on 2021-01-15 20:12:31
I tried disconnecting his PPPOE session, shortly afterward I get this request in the freeradius/radacct/NASIPADDRESS/ log files
Mon Jul 19 15:25:35 2021 Packet-Type = Access-Request That doesn't help. You need to look at your local configuration to see what happens with accounting packets, and where they're going.
Then, look in the accounting log files. Usually a "detail" file.
And the authentication is fine. But still the expiry_time isn't updated. I should se another Accounting request below that right? No.
Accounting packets get logged to different locations than authentication packets.
Alan DeKok.
On Jul 19, 2021, at 10:56 AM, Mirko Alberio <mirko.alberio@telemar.it> wrote:
Ok, thanks, I did some packet capture in the problematic NAS, accounting Stop packet are actually being sent, but still the table is not updated. I attach the capture. So the NAS is sending account data!
Please read my messages. The Stop packet isn't what is important. The interim update messages are important. It really helps to pay attention, and to understand what's going on. If you don't, then you'll be randomly changing irrelevant things, and nothing will get fixes.
And another quick question: we noticed also some cases where username deleted from the radcheck and radreply tables (dismissed customers) are still present in the radippool table, with past expiry_time: should not be automatically "pruned"?
No. That's not how RADIUS works. There is nothing which monitors the SQL database for changes, and kicks off users. Perhaps someone could write a script and submit it back to us...
Those customers for example could disconnect the router cable and the NAS is not able to send the Stop packet.
That's not how it works. If the session is stopped for ANY reason, then the NAS sends a stop packet. If the NAS doesn't do that, then throw it in the garbage, and buy a NAS which follows the RADIUS specifications. Alan DeKok.
Ok, sorry, but some thing that I assumed were right turned out wrong and many doubts pop up, so ok we found out that the NAS (Mikrotik) did not have the interim-update enabled, and so we are working to enable it. What would be a suggested time interval? Thanks! Mirko Alberio - Assistenza tecnica e-mail: mirko.alberio@telemar.it Telemar SpA Internet Quality Provider Via Enrico Fermi, 235 - 36100 Vicenza - Italia Tel 0444 291302 - Fax 0444 566310 - www.telemar.it Assistenza tecnica 0444 1420000 Reg. Imp. Di Vicenza /C.F./P.I. 02508710247 Cap. Soc. € 120.000,00 I.V. R.E.A. VI-236292 Il 19/07/2021 17:13, Alan DeKok ha scritto:
On Jul 19, 2021, at 10:56 AM, Mirko Alberio <mirko.alberio@telemar.it> wrote:
Ok, thanks, I did some packet capture in the problematic NAS, accounting Stop packet are actually being sent, but still the table is not updated. I attach the capture. So the NAS is sending account data! Please read my messages. The Stop packet isn't what is important. The interim update messages are important.
It really helps to pay attention, and to understand what's going on. If you don't, then you'll be randomly changing irrelevant things, and nothing will get fixes.
And another quick question: we noticed also some cases where username deleted from the radcheck and radreply tables (dismissed customers) are still present in the radippool table, with past expiry_time: should not be automatically "pruned"? No. That's not how RADIUS works.
There is nothing which monitors the SQL database for changes, and kicks off users. Perhaps someone could write a script and submit it back to us...
Those customers for example could disconnect the router cable and the NAS is not able to send the Stop packet. That's not how it works.
If the session is stopped for ANY reason, then the NAS sends a stop packet. If the NAS doesn't do that, then throw it in the garbage, and buy a NAS which follows the RADIUS specifications.
Alan DeKok.
On Jul 19, 2021, at 11:51 AM, Mirko Alberio <mirko.alberio@telemar.it> wrote:
Ok, sorry, but some thing that I assumed were right turned out wrong and many doubts pop up,
so ok we found out that the NAS (Mikrotik) did not have the interim-update enabled, and so we are working to enable it.
As I had mentioned at the start...
What would be a suggested time interval?
10 minutes is usually normal. Alan DeKok.
Ok, all clear, we enabled the interim-update on a sigle nas and captured the packets, now the Interim-request are being sent and received by the radius, another doubt: should radius update the expiry_time of the users connecting via that NAS in the radippool table when an interim update is received? Mirko Alberio Amministratore di Sistemi Via Enrico Fermi, 235 - 36100 Vicenza - Italia Tel 0444 291302 - Fax 0444 566310 - www.telemar.it <http://www.telemar.it> Reg. Imp. Di Vicenza /C.F./P.I. 02508710247 Cap. Soc. € 120.000,00 I.V. R.E.A. VI-236292 <https://it-it.facebook.com/TelemarIt/> <https://www.instagram.com/telemar_it/> <https://it.linkedin.com/company/telemar-s-p-a-> Il presente messaggio non costituisce offerta e/o accettazione contrattuale. Ai sensi del Regolamento europeo per la protezione dei dati personali n. 679/2016 (GDPR) si precisa che le informazioni contenute in questo messaggio e/o nel/i file/s allegato/i sono riservate ed a uso esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo e a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. Pursuant to General Data Protection Regulation (GDPR), you are hereby informed that this message contains confidential information intended only for the use of the addressee. If you are not the addressee, and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you. Il 19/07/2021 18:03, Alan DeKok ha scritto:
On Jul 19, 2021, at 11:51 AM, Mirko Alberio <mirko.alberio@telemar.it> wrote:
Ok, sorry, but some thing that I assumed were right turned out wrong and many doubts pop up,
so ok we found out that the NAS (Mikrotik) did not have the interim-update enabled, and so we are working to enable it. As I had mentioned at the start...
What would be a suggested time interval? 10 minutes is usually normal.
Alan DeKok.
On Jul 19, 2021, at 2:11 PM, Alberio Mirko <mirko.alberio@telemar.it> wrote:
we enabled the interim-update on a sigle nas and captured the packets, now the Interim-request are being sent and received by the radius,
another doubt: should radius update the expiry_time of the users connecting via that NAS in the radippool table when an interim update is received?
Yes. That's what the default configuration does, for a large number of reasons. Think about it this way... do you want the IP to expire 30 seconds after FreeRADIUS gets an update packet? Even if there's no "stop" packet? What would happen if the IP expired like that? The default configuration and queries *work*. Alan DeKok.
Hi Alan, just another confirm to check if I understood correctly: So now because of the misconfiguration of the NAS I have IPs in the radippool table assigned to users not existing anymore in the radius tables (users that ceased the service) with expiry_time in the past. If I update those users NAS and add the interim-update, should those record be cleared? And, speaking of expiry_time: what is in that case the best pratice, together with the 10 minutes interim-time? One hour (the default value) would be fine? Thanks! Mirko Alberio - Assistenza tecnica e-mail: mirko.alberio@telemar.it Telemar SpA Internet Quality Provider Via Enrico Fermi, 235 - 36100 Vicenza - Italia Tel 0444 291302 - Fax 0444 566310 - www.telemar.it Assistenza tecnica 0444 1420000 Reg. Imp. Di Vicenza /C.F./P.I. 02508710247 Cap. Soc. € 120.000,00 I.V. R.E.A. VI-236292 Il 19/07/2021 20:37, Alan DeKok ha scritto:
On Jul 19, 2021, at 2:11 PM, Alberio Mirko <mirko.alberio@telemar.it> wrote:
we enabled the interim-update on a sigle nas and captured the packets, now the Interim-request are being sent and received by the radius,
another doubt: should radius update the expiry_time of the users connecting via that NAS in the radippool table when an interim update is received? Yes. That's what the default configuration does, for a large number of reasons.
Think about it this way... do you want the IP to expire 30 seconds after FreeRADIUS gets an update packet? Even if there's no "stop" packet? What would happen if the IP expired like that?
The default configuration and queries *work*.
Alan DeKok.
On Jul 21, 2021, at 8:07 AM, Mirko Alberio <mirko.alberio@telemar.it> wrote:
So now because of the misconfiguration of the NAS I have IPs in the radippool table assigned to users not existing anymore in the radius tables (users that ceased the service) with expiry_time in the past.
Again, FreeRADIUS has no idea if the user is online or not. The only way that FreeRADIUS knows, is if the NAS sends it packets. There is no magic here. There's no need to worry about the FreeRADIUS behavior, or database tables, or whatever. Everything in the radacct database comes from the NAS. If the database isn't updated, then the NAS isn't sending packets to update it.
If I update those users NAS and add the interim-update, should those record be cleared?
If the NAS sends packets saying that the user is offline, then the user records will be cleared. If the NAS reboots, it sends an accounting "on" or "off" packet, and *all* records for users on that NAS will be cleared. You can go clear the records manually by editing the SQL database yourself. But if the user is still online, the NAS (may) eventually send a packet, and the record will be created. Stop worrying about the database, and go check if the user is still online. If the user is still online, then kick him off. And the NAS should send an accounting "stop" packet. If the NAS never sends a "stop" packet for a user session, well, it's either garbage, or misconfigured.
And, speaking of expiry_time: what is in that case the best pratice, together with the 10 minutes interim-time? One hour (the default value) would be fine? Thanks!
It's up to you. How long should the users stay online? That's the expiry time. Alan DeKok.
participants (3)
-
Alan DeKok -
Alberio Mirko -
Mirko Alberio