Re: IPSec client is alternating between two IP addresses
We are using freeradius version (debian) 2.1.12+dfsg-1.2
You really need to upgrade to 2.2.10. You don't have to change anything in your configuration.
to manage an ip-pool for an ipsec vpn gateway. The gateway does xauth to the radius server for authentication and IP assignment as well as accounting to e.g. clean up the IP address. Upon re-keying the user gets a new IP address (which is the same as the second to last one), so its basically alternating between two IP addresses. We are using the ippool- module (not SQL) and I already found the notes on the key-parameter. Its currently set to "%{NAS-IP-Address} %{User-Name}" which is unique for each dailed in client. Before we configured accounting on the vpn gateway the reason for the alternating IPs was quite obvious to me (from looking at the module code: "Found a stale entry for ip") but with accounting properly configured I can't find a reason why its still the same:
If the IP is still active, AND the query uses the same IP, then it should be renewed.
Even when I manually disconnect my VPN client (causing a deallocation message on freeradius-server side), and reconnect again (after a while) I will get the "other" IP. Is this inteded? What must our VPN client send while re-keying to not cause freeradius to swap the IP but to just "renew" it? BTW does "renew" mean it just updates some meta-date in the DB?
But... 2.1.12 is 6 years old. You should really upgrade. And take a serious look at v3, too.
Now with accounting its looking like this upon re-keying:
Jan 8 21:37:37 s030v0047 freeradius[30859]: [s030v0047-test_pool] #011expand: %{NAS-IP-Address} %{User-Name} -> 1.1.1.2 C023A0667 Jan 8 21:37:37 s030v0047 freeradius[30859]: [s030v0047-test_pool] MD5 on 'key' directive maps to: 4d7b2dcc10b9fa1a049fc4d1d05170c0 Jan 8 21:37:37 s030v0047 freeradius[30859]: [s030v0047-test_pool] Searching for an entry for key: '1.1.1.2 C023A0667' Jan 8 21:37:37 s030v0047 freeradius[30859]: [s030v0047-test_pool] Deallocated entry for ip: 10.151.222.215
In 2.2.10, it only prints "Deallocated entry" when the NAS sends an accounting STOP. i.e. when the session is closed.
Running the server in debugging mode will tell you what's going on...
The submitted logs were captured while running the server with "-xx"
But if the NAS sends a STOP before renewing the IP, well, that explains everything. The original session is gone, so a new lease is allocated.
When the old session is gone, why not handing out the same IP again for the new session, as long its the same requester, e.g. 4d7b2dcc10b9fa1a049fc4d1d05170c0 in my example?
Alan DeKok.
Thank you very much for your response.
On 10/01/2018, at 9:33 AM, Artur Jaroschek <artur@jaroschek.net> wrote:
Even when I manually disconnect my VPN client (causing a deallocation message on freeradius-server side), and reconnect again (after a while) I will get the "other" IP. Is this inteded?
Once an IP is deallocated, it is deallocated. There is no information stored about what IP was given out previously.
What must our VPN client send while re-keying to not cause freeradius to swap the IP but to just "renew" it? BTW does "renew" mean it just updates some meta-date in the DB?
Your NAS (i.e. VPN server) is probably sending an accounting Stop message. Tell it to not send that when re-keying. I would be surprised if it was simply re-keying, as it sounds like it is sending a new Access-Request as well (which is giving it the new IP). Why is it doing that? Is that what you expect? I would have a chat to your VPN vendor. Surely a re-key of an existing session doesn’t mean re-auth?
Running the server in debugging mode will tell you what's going on...
The submitted logs were captured while running the server with "-xx”
There are a number of places that say things like: "Always use radiusd -X when debugging!”
But if the NAS sends a STOP before renewing the IP, well, that explains everything. The original session is gone, so a new lease is allocated.
When the old session is gone, why not handing out the same IP again for the new session, as long its the same requester, e.g. 4d7b2dcc10b9fa1a049fc4d1d05170c0 in my example?
Because there is no information stored to relate the old deallocated IP to the new session. -- Nathan Ward
On 10/01/2018, at 9:33 AM, Artur Jaroschek <artur@jaroschek.net> wrote:
Even when I manually disconnect my VPN client (causing a deallocation message on freeradius-server side), and reconnect again (after a while) I will get the "other" IP. Is this inteded?
Once an IP is deallocated, it is deallocated. There is no information stored about what IP was given out previously.
But as key-parameter is unique for each "client" it always points to the same IP address for the same client coming in. See my second answer below.
What must our VPN client send while re-keying to not cause freeradius to swap the IP but to just "renew" it? BTW does "renew" mean it just updates some meta-date in the DB?
Your NAS (i.e. VPN server) is probably sending an accounting Stop message. Tell it to not send that when re-keying.
I would be surprised if it was simply re-keying, as it sounds like it is sending a new Access-Request as well (which is giving it the new IP). Why is it doing that? Is that what you expect? I would have a chat to your VPN vendor. Surely a re-key of an existing session doesnât mean re-auth?
Running the server in debugging mode will tell you what's going on...
The submitted logs were captured while running the server with "-xxâ
There are a number of places that say things like: "Always use radiusd -X when debugging!â
But if the NAS sends a STOP before renewing the IP, well, that explains everything. The original session is gone, so a new lease is allocated.
When the old session is gone, why not handing out the same IP again for the new session, as long its the same requester, e.g. 4d7b2dcc10b9fa1a049fc4d1d05170c0 in my example?
Because there is no information stored to relate the old deallocated IP to the new session.
I found this commend in the code: * --------------------------------------------- * - NAS/PORT Entry |||| Free Entry ||| Time * - IP1 IP2(Free) BEFORE * - IP2(Free) IP1 AFTER * --------------------------------------------- By saying "alternating" I mean exactly this. A client X always gets IP1 or IP2, eg. 10.151.222.214 and 10.151.222.20, than again 10.151.222.214 and so on. I found out that if the pool usage gets above a certain level than that client will always get IP1 as IP2 already is allocated to someone else.
-- Nathan Ward
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
On 10/01/2018, at 10:47 PM, artur@jaroschek.net wrote:
On 10/01/2018, at 9:33 AM, Artur Jaroschek <artur@jaroschek.net> wrote:
Even when I manually disconnect my VPN client (causing a deallocation message on freeradius-server side), and reconnect again (after a while) I will get the "other" IP. Is this inteded?
Once an IP is deallocated, it is deallocated. There is no information stored about what IP was given out previously.
But as key-parameter is unique for each "client" it always points to the same IP address for the same client coming in. See my second answer below.
No it doesn’t. See below for more info, and data.
What must our VPN client send while re-keying to not cause freeradius to swap the IP but to just "renew" it? BTW does "renew" mean it just updates some meta-date in the DB?
Your NAS (i.e. VPN server) is probably sending an accounting Stop message. Tell it to not send that when re-keying.
I would be surprised if it was simply re-keying, as it sounds like it is sending a new Access-Request as well (which is giving it the new IP). Why is it doing that? Is that what you expect? I would have a chat to your VPN vendor. Surely a re-key of an existing session doesnât mean re-auth?
Running the server in debugging mode will tell you what's going on...
The submitted logs were captured while running the server with "-xxâ
There are a number of places that say things like: "Always use radiusd -X when debugging!â
I note that there is still no debug posted.
But if the NAS sends a STOP before renewing the IP, well, that explains everything. The original session is gone, so a new lease is allocated.
When the old session is gone, why not handing out the same IP again for the new session, as long its the same requester, e.g. 4d7b2dcc10b9fa1a049fc4d1d05170c0 in my example?
Because there is no information stored to relate the old deallocated IP to the new session.
I found this commend in the code:
* --------------------------------------------- * - NAS/PORT Entry |||| Free Entry ||| Time * - IP1 IP2(Free) BEFORE * - IP2(Free) IP1 AFTER * ——————————————————————
Yes, I believe from reading the code that the idea here is to re-use the key object and point it to a different data object. This does not describe the symptom you see.
By saying "alternating" I mean exactly this. A client X always gets IP1 or IP2, eg. 10.151.222.214 and 10.151.222.20, than again 10.151.222.214 and so on. I found out that if the pool usage gets above a certain level than that client will always get IP1 as IP2 already is allocated to someone else.
I understand why you think that that behaviour is that the one end user is alternating between two different IPs. That will happen if you have only one user. If you have two users, the following will happen: 1) Client A connects, gets IP 1 2) Client A re-connects (Stop + Access-Request), gets IP 2 3) Client B connects, gets IP 1 4) Client A re-connects (Stop + Access-Request), gets IP 3 5) Client B re-connects (Stop + Access-Request), gets IP 2 6) Client A re-connects (Stop + Access-Request), gets IP 1 7) Client B re-connects (Stop + Access-Request), gets IP 3 Here is proof: 1) /projects # radclient -f conn_a 127.0.0.1 auth testing123 Received response ID 148, code 2, length = 32 Framed-IP-Address = 192.168.1.215 <- IP 1 Framed-IP-Netmask = 255.255.255.0 2) /projects # radclient -f discon_a 127.0.0.1 acct testing123 Received response ID 150, code 5, length = 20 /projects # radclient -f conn_a 127.0.0.1 auth testing123 Received response ID 206, code 2, length = 32 Framed-IP-Address = 192.168.1.43 <- IP 2 Framed-IP-Netmask = 255.255.255.0 3) /projects # radclient -f conn_b 127.0.0.1 auth testing123 Received response ID 28, code 2, length = 32 Framed-IP-Address = 192.168.1.215 <- IP 1 Framed-IP-Netmask = 255.255.255.0 4) /projects # radclient -f discon_a 127.0.0.1 acct testing123 Received response ID 70, code 5, length = 20 /projects # radclient -f conn_a 127.0.0.1 auth testing123 Received response ID 66, code 2, length = 32 Framed-IP-Address = 192.168.3.251 <- IP 3 Framed-IP-Netmask = 255.255.255.0 5) /projects # radclient -f discon_b 127.0.0.1 acct testing123 Received response ID 6, code 5, length = 20 /projects # radclient -f conn_b 127.0.0.1 auth testing123 Received response ID 164, code 2, length = 32 Framed-IP-Address = 192.168.1.43 <- IP 2 Framed-IP-Netmask = 255.255.255.0 6) /projects # radclient -f discon_a 127.0.0.1 acct testing123 Received response ID 123, code 5, length = 20 /projects # radclient -f conn_a 127.0.0.1 auth testing123 Received response ID 186, code 2, length = 32 Framed-IP-Address = 192.168.1.215 <- IP 1 Framed-IP-Netmask = 255.255.255.0 7) /projects # radclient -f discon_b 127.0.0.1 acct testing123 Received response ID 186, code 5, length = 20 /projects # radclient -f conn_b 127.0.0.1 auth testing123 Received response ID 176, code 2, length = 32 Framed-IP-Address = 192.168.3.251 <- IP 3 Framed-IP-Netmask = 255.255.255.0 This is because it is selecting addresses in order - it just appears to you with limited testing to behave as though it is swapping addresses back and forward, as the order of the IP addresses coming out is not chosen numerically. I will note that it is not immediately clear to my why it gives out the next free address, rather than the current address as that is now marked free. I think it is because of how the gdbm keys are iterated through. If for example you alternate between Client A and Client B being connected, so that they are not connected at the same time, you get something similar. 1) Client A connects, gets IP 1 2) Client A disconnects 3) Client B connects, gets IP 2 4) Client B disconnects 5) Client A connects, gets IP 3 6) Client A disconnects 7) Client B connects, gets IP 1 8) Client B disconnects 9) Client A connects, gets IP 2 10) Client A disconnects etc. Additionally, if you send Stop, the IP address is released to the pool for re-assignment. Even if you were able to make a subsequent Access-Request issue the same address, you may still have a race condition where a re-key or a new connection comes between the Stop and the Access-Request messages. Again, I urge you to consider what is going on in your NAS - why is it sending a Stop message if it does not want to stop the session? That is broken, and it needs to be fixed. The response to the Access-Request could be an Access-Challenge if you decided to implement 2 factor authentication or something. What now? The user has to enter their hardware token each time that your NAS wants to re-key? -- Nathan Ward
On Jan 10, 2018, at 6:54 AM, Nathan Ward <lists+freeradius@daork.net> wrote:
This is because it is selecting addresses in order - it just appears to you with limited testing to behave as though it is swapping addresses back and forward, as the order of the IP addresses coming out is not chosen numerically. I will note that it is not immediately clear to my why it gives out the next free address, rather than the current address as that is now marked free. I think it is because of how the gdbm keys are iterated through.
The code would need to be updated to add a check for the current key, *before* checking for a free IP. e.g. get IP(key) if IP is free return that else get free IP Which is essentially what the sqlippool module does in v3: SELECT framedipaddress FROM ${ippool_table} \ WHERE pool_name = '%{control:Pool-Name}' \ AND (expiry_time < NOW() OR expiry_time IS NULL) \ ORDER BY \ (username <> '%{User-Name}'), \ (callingstationid <> '%{Calling-Station-Id}'), \ expiry_time \ LIMIT 1 \ FOR UPDATE" i.e. get me free IP based on User-Name or Calling-Station-Id. If there's no matching IP, just allocate an expired one.
Additionally, if you send Stop, the IP address is released to the pool for re-assignment. Even if you were able to make a subsequent Access-Request issue the same address, you may still have a race condition where a re-key or a new connection comes between the Stop and the Access-Request messages.
Yes. If the OP wants static IPs, he should configure static IPs. Using a "dynamic IP" module means that the IPs can change.
Again, I urge you to consider what is going on in your NAS - why is it sending a Stop message if it does not want to stop the session? That is broken, and it needs to be fixed. The response to the Access-Request could be an Access-Challenge if you decided to implement 2 factor authentication or something. What now? The user has to enter their hardware token each time that your NAS wants to re-key?
There are entirely too many broken NASes. And entirely too many people who wonder why "FreeRADIUS" is doing something, when the debug log shows that it's the fault of the NAS. Alan DeKok.
On Jan 10, 2018, at 4:47 AM, artur@jaroschek.net wrote:
But as key-parameter is unique for each "client" it always points to the same IP address for the same client coming in.
Only during a session. The difficulty with RADIUS is that there are multiple packets (Access-Request, followed by Accounting-Request). If you want the Accounting-Request packets to cause the IP to be marked "still in use", or "stopped using it", then you need a key which identifies that session. Because not all NASes are smart enough to include Framed-IP-Address in accounting packets... i.e. if your expectations differ from what the server does, then your expectations are wrong. You should upgrade to v3, where both the documentation and debug output are better.
By saying "alternating" I mean exactly this. A client X always gets IP1 or IP2, eg. 10.151.222.214 and 10.151.222.20, than again 10.151.222.214 and so on. I found out that if the pool usage gets above a certain level than that client will always get IP1 as IP2 already is allocated to someone else.
Which is entirely consistent with the idea that IPs are assigned based on availability, *not* on a key. And all of this is moot. Who cares that the IPs change? It shouldn't be a problem. If it is a problem, then stop arguing about how the module "should" work. It clearly doesn't do what you want. We WILL NOT "fix" v2. Upgrade to v3, and use the sqlippool module. That is better documented, and you can more easily tweak it's behaviour. Alan DeKok.
participants (4)
-
Alan DeKok -
Artur Jaroschek -
artur＠jaroschek.net
-
Nathan Ward