Issues with subnet like 172.16.0.128/29

Pritunl Pritunl VPN
1

Hello,

I’m facing issues that I’m not able to understand why they happen.
The setup I have is as follows:

AWS EC2 instance t3.micro with Oracle Linux 9 setup as it is described here but with Mongodb Atlas.
Server with subnet 172.16.0.128/29 and 3 peers that are attached to it using Group.
The issue I’m experiencing is as follows:
When initially connect all the peers to the server there aren’t any issues but once you disconnect any of the peers(no matter who) and try to reconnect it back again I’m facing the following error:

staging][2025-04-14 15:02:55,580][ERROR] User missing ip address
  server_id    = "67f91a72bb4fe5932cc45e0f"
  instance_id  = "67fd1f4be55d385c4c2f41c3"
  user_id      = "67f91a72bb4fe5932cc45df5"
  multi_device = false
  network      = "172.16.0.128/29"
  user_count   = 6
Traceback (most recent call last):
  File "/usr/lib/pritunl/usr/lib/python3.9/threading.py", line 937, in _bootstrap
    self._bootstrap_inner()
  File "/usr/lib/pritunl/usr/lib/python3.9/threading.py", line 980, in _bootstrap_inner
    self.run()
  File "/usr/lib/pritunl/usr/lib/python3.9/threading.py", line 917, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/callqueue.py", line 34, in _thread
    queued = self.call(timeout=0.5)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/callqueue.py", line 25, in call
    func(*args, **kwargs)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/clients/clients.py", line 1427, in _connect
    auth.authenticate()
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/authorizer/authorizer.py", line 154, in authenticate
    self._callback(True)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/authorizer/authorizer.py", line 215, in _callback
    self.callback(allow, reason=reason, doc_id=self.doc_id)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/clients/clients.py", line 1361, in callback
    self.allow_client(client_data, org, user,
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/clients/clients.py", line 883, in allow_client
    self.get_virt_addr(org_id, user_id, mac_addr, doc_id)
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/clients/clients.py", line 612, in get_virt_addr
    logger.error('User missing ip address',
  File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/logger/__init__.py", line 55, in error
    kwargs['traceback'] = traceback.format_stack()

Another think that I’m observing as an issue is related to the time it takes for the server to understand that a peer has been disconnected - basically it takes approximately 5-10 minutes before the server realize that a peer is no longer connected to the server. Could you share your thoughts on this issues and tell me how can I solve them ?

2

The timeouts can be adjusted in the settings. For OpenVPN connections the ping interval can be reduced to 5 and ping timeout to 10. For WireGuard the ping interval can be reduced to 5 and timeout to 10 only on newer versions of the server and client. Older client versions do not have a variable WireGuard interval and will timeout if the timeout is below 60.

3

What about this error ?

4

image
image597×531 15.9 KB

I’m using default configuration but still it takes more than 5 minutes for the server to realize the peer is not longer connected and as I described in my initial inquire once a peer is disconnected it is no longer able to reconnect due to the ERROR from above.

5

The missing IP error is because the subnet is too small. It’s likely causing IP database to lose track of IP addresses. Even if the user connected from a different device while the other connection is still active normally it will reclaim the address and disconnect the other device when multi device is disabled. This isn’t working because IP addresses can’t be fully assigned with a subnet that small.

There hasn’t been enough development or testing for a configuration like that. It was designed with the assumption there would be a lot of extra space in the subnet. When it is undersized a background task that checks the consistency of the IP pool will continue to try to correct the IP assignments and cause unintentional errors.

6

Having that said should this be considered as behavior by design and what you are recommending is to use bigger networks?
Also is there any recommended minimum subnet that can be used and not causing issue?

7

I went through the code and made several changes to remove assignment of IP addresses to pooled users and server users. This should fix any issues with IP addresses being overutilized. This will be included in the next release.

This configuration still won’t work user_count = 6 is too many users for a /29. The first address will be used by the server, that subnet can only have 5 users.

8

When should we expect this release?

9

OK,

After conducting a thorough review of the database and its stored information, I identified the root cause of the issue. It appears that every user within the same organization is assigned a static IP for every server associated with that organization—even though restrictions indicate that, for example, A-user should only connect to Server1 because they are in the same group.

Moreover, the static IP assignment follows an alphabetical order. This approach can create complications: if there are many users but the subnets are relatively small, you might not have enough static IPs available for binding to a specific server, as the IPs for that server may already be allocated to users earlier in the alphabetical sequence. For instance, even if A-user is limited to accessing only Server1, they might still receive a static IP for Server2.

Could you confirm if I am mistaken? Is this behavior intentional, and if so, what is its purpose? In my opinion, it would be more appropriate for A-user to receive a static IP only for the server they are authorized to access, which in this case is Server1.

10

That is intentional user groups do not determine if an IP will be assigned. Groups can be added or removed when connecting and while connecting so the IP address stays assigned. Not doing this would make the system very unpredictable. If an administrator removed a group and added a different one than had the single sign-on assign that new group which would be synced on the next connection all IP addresses would be unassigned than assigned again.

11

This would also means that my network has minus N number of users available IPs for assignment e.g if I have the network 172.16.0.128/29 and I have 10 users in alphabetic order but I would like to use it with users which are in the end of the sequence of this 10 users I won’t be able because first 5 users will take the available IPs of the network. The only way would be to use separate Organization to achieve the segmentation I’m aiming for, is that correct?

12

Yes no further changes are going to be made for that limited use case.

1 Like