We’re seeing the following error in the logs of two different VPN hosts:
[host-vpn-02][2025-08-01 04:07:00,488][ERROR] Failed to assign IP, retrying pool server_id = "xxxxx...4259" org_id = "xxxxx...1fe" user_id = "xxxxx...37d" [host-vpn-01][2025-07-31 04:07:00,491][ERROR] Failed to assign IP, retrying pool server_id = "xxxxx...4259" org_id = "xxxxx...763" user_id = "xxxxx...d8c"
What’s strange is that both hosts are not attached to the server shown in the logs.
We also noticed that the organization ID is used in more than one server, but this specific server is not active on the hosts where the errors are happening.
Do you know what might be causing this?
Thanks in advance for any help!
This is a background task that assigns static IP addresses from the server virtual networks to users. It can run on any host. Verify that the virtual server subnet is large enough for all the users attached.
What I don’t understand is that the hosts mentioned in the alert are not attached to the server in question.
In my environment, I have three hosts, and this specific server is linked only to host 03.
However, the alert is referring to hosts 01 and 02.
I have some organizations attached to this server, with a total of a little over 160 users.
However, within those organizations, only the users who have the group tag — which I set on the server — actually have access to it in the Pritunl profile.
So, only a bit more than 10% of those users would ever be online at the same time.
I’m currently using a /25 range, which easily supports that number.
My question is: are users who don’t have the group tag and can’t access the server still being counted when static IPs are assigned?
Would I need to switch to a /24 range just to support all users, even the ones who don’t use this server?
Could you please give me a more technical explanation of this behavior?
The host shown in the logs is the host that ran the IP assignment task. It doesn’t need to be the same host that the server runs on. The tasks are distributed across all hosts in the cluster.
Groups can change at the time of connection so IP addresses are assigned even if the groups don’t match. The size of the subnet needs to have space for all users in organizations attached to the server.
Thanks, Zach! That makes sense.
I understand now that the host in the logs is just the one handling IP assignment, not necessarily the server host, and that tasks are spread across the cluster. Also, noted about group changes and subnet size.