APM-DHCP Access Policy Example and Detailed Instructions

Hi  :

Thank you for the clear problem description. I will explain in detail below, but to summarize first, in the APM-DHCP version you have (v3d+) you have discovered one outright error in the documentation and one awkwardness (not a strictly a bug) in the code that handles DHCPRELEASE. (The documentation error is fixed in version v3f and later.)

Since you described two different users getting the same IP address, here is an simple, instant fix for you: in your Access Policy, in your DHCP_Setup Variable Assign Item, add the following setting

session.dhcp.client_ID  =  '' (that is, two single-quotes, no spaces)

That change will almost certainly fix your current problem because you are not assigning IP's to specific users (if you were, then User1 and User2 would not get the same IP, regardless of the problem with delayed DHCPRELEASE messages).

Right now your DHCP server gives User1 the same IP for both his first and second APM VPN sessions because your DHCP server sees the MAC address of his device (laptop or whatever) in the DHCP requests for both of his VPN sessions. The DHCP server thinks "it's the same client device, might as well give it the same IP address." When you set session.dhcp.client_ID to '' (two single-quotes) as I recommend, APM-DHCP will start sending your DHCP server a unique client-device identifier for each session, so the DHCP server will give User1 different IP's for his first and second sessions. That way User2 will not get an IP which conflicts with User1's IP even when the DHCPRELEASE for User1's first session is tardy.

If you actually did wish to tie specific static IP addresses to specific users then the quick fix would not be applicable, but the problem would never appear (because each user would always get his/her own static IP). However, for F5 customers whose DHCP servers reserve certain IP's for certain groups of users there could still be a problem...

Here's the long explanation. FIrst, the error in the documentation. I regret that you were misled. That advice-- to use a monitor to prompt release of DHCP IP's-- has been outdated and ineffective since I changed the actual code in the solution several years ago. I just failed to notice and remove that line or two in the doc at that time.

Second, the awkwardness in the code. Currently (that is, up to and including version v3g -- I do realize you have v3d+) for good reasons the code which sends DHCPRELEASE messages after APM VPN sessions end can delay up to four minutes even on a busy APM device, and will send the DHCPRELEASE for a terminated session even if the actual IP has since been assigned to a new session.

The reason for the delay in sending DHCPRELEASE after a session ends is that no iRule can send any messages just at the moment when a VPN session ends. APM does fire an iRule event then called ACCESS_SESSION_CLOSED, but no network messages can be sent from that event, nor can any shared-memory locations be updated. The APM-DHCP solution has to wait for some other iRule event to check which APM sessions have recently ended and then send DHCPRELEASE messages for those recently-terminated sessions.

APM-DHCP uses the CLIENT_ACCEPTED event for the next client connection to clean up after recently-ended sessions. However, APM-DHCP cannot just transmit each DHCPRELEASE message from CLIENT_ACCEPTED. Every possible local-and-remote IP:port combination is mapped to just one of several TMM processes on the BIG-IP by the "DAG" (traffic disaggregator) which distributes network connections evenly to TMM processes. That means that only one TMM can actually send DHCP messages from the BIG-IP's UDP port 67 (on the proper IP address) to a particular DHCP server's port 67. Therefore, APM-DHCP queues up DHCPRELEASE messages to be sent from the "right" TMM the next time that TMM handles some DHCPREQUEST traffic to the target DHCP server (many customer environments have multiple DHCP servers-- this is normal-- and each one may be mapped to a different TMM process).

Worse yet, if APM-DHCP were actually to check on all VPN sessions upon every client connection it would harm the performance of busy APM devices. Suppose that some (rather modest) APM device supports 1,500 simultaneous VPN sessions and the average duration of each session is 4 hours. Then by Little's Law that APM device accepts about ten connections per second on average. If APM-DHCP tried to poll APM for the status of 1,500 sessions 10 times per second neither the APM administrator nor the APM users would be pleased. To avert performance problems, APM-DHCP currently polls for the status of any given session only once every four minutes. That means the average delay between a session ending and APM-DHCP noticing is two minutes. Awkwardly, per your report that seems to be enough time for a user to log in, drop his session, then log in again before APM-DHCP notices his first session has ended-- meaning the DHCPRELEASE for his first session may be sent out after his second session has begun.

But wait (says Ron Popeil), there's more! Even when APM-DHCP is finally about to transmit a DHCPRELEASE message, it (currently) has no good way to know whether the client IP inside that message has been leased to a new VPN session. APM-DHCP knows the session-ID of the old, closed session and the IP that the old session had, but there is no easy way for APM-DHCP to ask APM whether any active session (with an new, different session-ID) is using that IP.

To avert the race condition you described  it will be necessary for APM-DHCP to track all the DHCP IP's in use. It could do that by rummaging through the DHCPRELEASE messages it has stashed waiting for their corresponding sessions to end, but that would be inefficient since those are indexed by session-ID, not IP. I will look into this and try to supply an update to APM-DHCP that alleviates the difficulty you described.