How does OpenVPN server assign client IP addresses in case of multiclient configuration?

Question

For a multiclient OpenVPN configuration, as we can find from the relevant documentation (server.conf comments),

Configure server mode and supply a VPN subnet for OpenVPN to draw client addresses from. The server will take 10.8.0.1 for itself, the rest will be made available to clients. Each client will be able to reach the server on 10.8.0.1.

server 10.8.0.0 255.255.255.0

So, as we understand, we are actually assigning a pool 256 addresses, the first usable address being 10.8.0.1 and the last usable should be 10.8.0.254. Among these, the first of the addresses (10.8.0.1) will be assigned to the server, as already made explicit in the above text.

Also, in the client configuration file, we find something like,

The hostname/IP and port of the server. You can have multiple remote entries to load balance between the servers.

remote my-server-1 1194

Where, the last line, as I deduce, should be written as,

remote 10.8.0.1 1194

in order to match with the server address.

(This statement is not correct, see this answer.)

Now, my question is, which algorithm does the sever follow in order to assign addresses to the client from the pool of available addresses (10.8.0.2-10.8.0.254)?

Is it something like that the first client gets the .2 address, the next one .3 address? Or is it that addresses are assigned at random? Or is it something else, if it is .5, 9., why is it like that?

Answer 1

OpenVPN doesn't document the exact algorithm it uses to find free addresses in the pool because it's an implementation detail and it doesn't really matter as long as it's a free address. Nevertheless, you can see what algorithm it uses by looking at the function ifconfig_pool_find in pool.c:

• If in duplicate_cn mode, take the first free address.
• If the IP address previously used by the same client is still free, select it.
• Otherwise, pick the least recently used free address from the pool.

As for your other question:

remote 10.8.0.1 1194

No, you definitely shouldn't use that as the remote address. Since you try to reach the tunnel server through the tunnel itself and the tunnel isn't set up yet at this point (during initialization) you cannot contact the server. If you somehow could establish the tunnel, you'd then have a routing loop.

In order to establish the tunnel, you need to have an IP address on which you can contact the other endpoint of the tunnel without benefit of the tunnel. This would normally be a reachable public Internet address for that endpoint. That's what you have to give for remote.