topic sending Radius accounting data to Checkpoint Identity Awareness in ZoneDirector

sending Radius accounting data to Checkpoint Identity Awareness

bruce_richards1 — Wed, 15 Jun 2016 14:49:15 GMT

Hi,

we are using Checkpoint's Identity Awareness feature to keep track of users to allow internet access. This basically maps IP addresses to AD accounts. One way to update this system is using Radius accounting which is ideal for WiFi.

We have our Zonedirector set up to send accounting packets to Checkpoint and this works well giving the user access to the internet seamlessly.

However .... when a user roams to another AP the Indentity Awareness looses the association between IP and username. As neither has changed this can only be because Zonedirector has sent a packet to Checkpoint to say that the user has left that AP and not sent another to tell the user it has reassociated to the new AP.

Is there anything I can do to fix this behaviour ?

Thanks for reading

Bruce

Re: sending Radius accounting data to Checkpoint Identity Awareness

bruce_richards1 — Mon, 20 Jun 2016 11:09:38 GMT

Update: packet captures show that the accounting packets are going out in this order

User Connects to AP1: Start Packet
User roams to AP2: Start Packet, Stop Packet.

If you look at the Session IDs for the packets then you can see that the Stop relates to AP1, but Checkpoint is ignoring Session ID and breaking the connection on Stop.

Re: sending Radius accounting data to Checkpoint Identity Awareness

michael_brado — Tue, 21 Jun 2016 23:33:30 GMT

This might take some help from CheckPoint Bruce...

Re: sending Radius accounting data to Checkpoint Identity Awareness

bruce_richards1 — Wed, 22 Jun 2016 07:57:25 GMT

Agreed, I'm asking the same questions of both parties and getting similar responses. I think that Ruckus are on higher ground as Checkpoint are ignoring the Session IDs but introducing a fraction of a second delay on the Start packets does fix the issue.

At the moment I'm working round the issue by using FreeRADIUS to introduce a 0.5 sec delay on the start packets.