Correction: I mentioned the above based on first hand information from the logs and a chat with support. Fortunately the guys from the SK team are very thorough when working on SK documentation and they imply that this is actually a bug and that using IPs from the pool SHOULD be possible.
Thank you for providing your feedback to SecureKnowledge on sk33422, titled "Office Mode IP and ipassignment.conf file".
Your feedback was:
Neither of the documentation mentions the fact that the IP used in ipassignment.conf MUST NOT be part of the pool. We found out the hard way, see these logs:
[vpnd 11166 4092880800]@FW1[6 Jul 16:34:44] registerAssignedIP: registering non-protected IP c0a8f80b to user user2 for 900 seconds in kernel instance 0
[vpnd 11166 4092880800]@FW1[6 Jul 16:34:44] registerAssignedIP: IP c0a8f80b already belongs to user user1. User user2 registration must fail.
After checking with RnD, they verified in the code that upon Policy install, the ipassignment.conf file is parsed and save the specified OMs in a local hash table, and during the negotiations, there is a check if the OM is already in the on_assigned_ips kernel table.
There might be a limitation in the code, however to investigate this we will need the vpnd logs from the time of the issue.
In case the issue will happen again please open a new service request with the logs.