Opened 5 years ago

Closed 2 years ago

#1274 closed Bug / Defect (fixed)

IP address pool for Openvpn clients

Reported by: hx5s6 Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

When configuring the server subnet using <network ip>/29, say 192.168.4.0/29, I expected to get 8 IP addresses. Among the 8 addresses, 3 would be for network (.0), server(.1), and broadcast(.7), and thus the remaining 5 would be available for client use. But the actual return is 4 via the following logic in pool.c:ifconfig_pool_init.

switch (type)
{

case IFCONFIG_POOL_30NET:

pool->base = start & ~3;
pool->size = (((end | 3) + 1) - pool->base) >> 2;
break;

case IFCONFIG_POOL_INDIV:

pool->base = start;
pool->size = end - start + 1; this is for my case
break;

default:

ASSERT(0);

}

The values of "start" and "end" above are the starting IP address and ending address calculated in helper.c:helper_client_server as follows.

if (o->server_defined)
{

int netbits = -2;
if (dev == DEV_TYPE_TUN)
{

int pool_end_reserve = 4; does this variable matter for the case where (topology == TOP_SUBNET)?

if (netbits > 29)
{

msg(M_USAGE, "--server directive when used with --dev tun must define a subnet of %s or lower",

print_netmask(29, &gc));

}

if (netbits == 29)
{

pool_end_reserve = 0;

}

o->mode = MODE_SERVER;
o->tls_server = true;

if (topology == TOP_NET30
topology == TOP_P2P)

{

...

}
else if (topology == TOP_SUBNET) this is for my case
{

o->ifconfig_local = print_in_addr_t(o->server_network + 1, 0, &o->gc);
o->ifconfig_remote_netmask = print_in_addr_t(o->server_netmask, 0, &o->gc);

if (!(o->server_flags & SF_NOPOOL))
{

o->ifconfig_pool_defined = true;
o->ifconfig_pool_start = o->server_network + 2; "start" would be .2 which is what I expected
o->ifconfig_pool_end = (o->server_network | ~o->server_netmask) - 2;
"end" would be .5 but I expected .6
ifconfig_pool_verify_range(M_USAGE, o->ifconfig_pool_start, o->ifconfig_pool_end);

}

I noticed that there is a variable, "pool_end_reserve", initialized as "4". But it is not used when "(topology == TOP_SUBNET)". I wonder if the logic to calculate the value of "end" namely "o->ifconfig_pool_end" is wrong. When the network source is limited, the pool size (5 or 4) does matter.

Please comment and Thanks.

Change History (6)

comment:1 Changed 5 years ago by Selva Nair

The "last" address is reserved for the fake DHCP server that Windows clients use. I have a forgotten patch out there [1] to use the network address for this purpose making the last address included in the pool. For now you can manually assign (i.e., push) the last IP to a non-Windows client.

[1] https://sourceforge.net/p/openvpn/mailman/message/34674818/

comment:2 Changed 5 years ago by hx5s6

Thanks for the quick reply. When saying "you can manually assign (i.e., push) the last IP to a non-Windows client", did you mean I DO or do NOT need to apply the "forgotten patch"?

comment:3 in reply to:  2 Changed 5 years ago by Selva Nair

Replying to hx5s6:

Thanks for the quick reply. When saying "you can manually assign (i.e., push) the last IP to a non-Windows client", did you mean I DO or do NOT need to apply the "forgotten patch"?

If you want the address included in the pool and/or use it on Windows, the patch is required. The address itself is usable as is on, say, a Linux client, without any patch. E.g., with server 10.10.0.0 255.255.255.0, you can do ifconfig-push 10.10.0.254 255.255.255.0
from ccd to a Linux client, but not to a Windows client that uses the default emulated DHCP for address assignment.

comment:4 Changed 5 years ago by hx5s6

Got it. Thanks again.

comment:5 Changed 4 years ago by Gert Döring

@Selva: is there anything to do on this ticket, or basically "user question, behaviour explained, nothing more to do"?

comment:6 Changed 2 years ago by Gert Döring

Resolution: fixed
Status: newclosed

I'll close this ticket now - seems there is nothing to do, and the forgotten patch was rediscovered and applied. Thanks, everyone.

Note: See TracTickets for help on using tickets.