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: 1. access-request nas-port-id = 100 2. access-accept framedipaddress = 192.168.1.100 3. acct-start acctsessionid = 4B151C655A0000 nas-port-id = 100 framedipaddress = 192.168.1.100 4. acct-stop nas-port-id = 100 framedipaddress = 192.168.1.100 acctterminatecause = user-request 5. access-request nas-port-id = 100 6. access-accept framedipaddress = 192.168.1.100 7. acct-start acctsessionid = 4B151C685A0001 nas-port-id = 100 framedipaddress = 192.168.1.100 I am assuming the radius packet for #5 actually arrives before the accounting stop in #4, thus the accounting-stop then marks the IP free, and the problem occurs. Bah. I can probably work around this by unallocating the "allocate-clear" query in rlm_sqlippool. Sick..