IPSec client is alternating between two IP addresses

[Nathan Ward]

Hi,

> On 10/01/2018, at 10:47 PM, artur at jaroschek.net wrote:
> 
>> 
>>> On 10/01/2018, at 9:33 AM, Artur Jaroschek <artur at 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