Phil Mayers wrote:
Phil Mayers wrote:
All,
I've just become aware of a rather annoying problem with our PPTP VPN server. Sometimes, a client will connect, disconnect and reconnect in quick succession. In these circumstances, there seems to be a window which an IP can remain allocated to a live VPN session, but is marked as free in the SQL table, causing subsequent clients to connect, be allocated the IP, and fail to get any connectivity.
ACK!
Shortly after sending this email, we found the problem and it's truly vile. It's nothing to do with FreeRadius at all, except tangentially - what's actually happening is that the PPTP client is closing the PPP LCP layer and re-opening it on the same PPTP control/data channel.
This results in a very rapid set of:
Ugh. Even worse, it doesn't actually re-authenticate the user; it actually just tears down the IPCP layer, and then brings it back up again USING THE SAME IP. Of course, since the "stop-clear" query has run at that point and re-set the pool_key column to "0", so the 2nd accounting start doesn't re-allocate the IP. That is, it does: access-request allocate-ip update pool set nas=%{NAS},pool_key=${pool-key} where ip=%I accounting-start update pool set expires=now()+x where nas=%{NAS} and pool_key=${pool-key} accounting-stop update pool set expires=now()-1,pool_key=0 where nas=%{NAS} and pool_key=${pool-key} accounting-start update pool set expires=now()+x where nas=%{NAS} and pool_key=${pool-key} FAILS because pool_key=0 now Bah. Bah bah bah.