|
From: James Y. <ji...@yo...> - 2004-10-21 23:19:35
|
On Thu, 21 Oct 2004, Mathias Sundman wrote: > I'm testing the new --ifconfig-pool-persist option with beta14. > > If I have a client-config-dir file using ifconfig-push to push a specific > IP address, this is still pushed to the client as it should, but there is > also assigned an IP address out of the generic ifconfig-pool and written > to the ifconfig-pool-persist file. > > Example: > > My openvpn config file contains: > client-config-dir /etc/openvpn/clients-config > ifconfig-pool 10.105.13.100 10.105.13.120 > ifconfig-pool-persist /etc/openvpn/openvpn.dhcp 30 > > and my own client-config-file contains: > ifconfig-push 10.105.11.3 255.255.0.0 > > 10.105.11.3 is pushed to my client when I connect, but the > ifconfig-pool-persist file contains: > Mathias.Sundman,10.105.13.100 > > > Bug or Works-As-Designed? The code is working as designed. When the connection is initialized, a pool address is allocated, then quickly deleted because you pushed your own address. But this allocation/deletion leaves behind an association because the persist file is really about past sessions that have been closed (if the persist file only recorded open sessions it would be empty on daemon shutdown). Remember that the persist file does not indicate IP address ownership. Rather, it indicates a suggestion of an association between IP and common name which is non-mandatory. So the lease file essentially says that if Mathias.Sundman connects (without an --ifconfig-push) use 10.105.13.100. But it's only a hint in the sense that if you ran out of pool addresses, and 10.105.13.100 wasn't actually being used by anyone, it would be taken by the next client regardless of its common name. Now having said that, I see how this could be confusing. It might be better to do a hard delete on the association if it is superceded by an --ifconfig-push, or not do the ephemeral alloc/delete cycle in the first place. James |