[strongSwan] Static Pool Configuration for a Server in 'Road warrior' configuration model
Krishna G, Suhas (Nokia - IN/Bangalore)
suhas.krishna_g at nokia.com
Fri Apr 10 07:04:02 CEST 2015
My test results and strongswan code browse for a use case have led to below understanding.
Use Case :
Client requests for a virtual IP from server.
Server assigns a virtual IP to it.
Client get rebooted without informing Server - i.e. Server still maintains the old lease, DPD kicks in for this lease at server.
Client comes up (before DPD at server for old lease has expired) and asks for another virtual IP.
Server assigns a new virtual IP.
1. The old lease becomes unusable. Server is not able to assign the old Iease to any new connection.
2. After the DPD expires for old lease at server, the client identity (even with new lease) is marked as 'offline'.
Understanding from Code Browse :
1. At client request, a 'put' is performed on 'online' hashtable. This 'put' function creates an entry in the hashtable if entry for 'key'(client identity) does not exist, but if the 'key' exists, replaces the current value(old lease) with new one(new lease).
What will be the destiny of old lease in a case where the old lease has not been even moved to 'offline' hashtable?
Entries that go to 'offline' hashtable(say, when DPD expires) alone are the ones that get reused in case of pool exhaustion.
So, in case a client requests for a second virtual IP, even before the old virtual IP has been moved to 'offline' hashtable, the old lease gets replaced in 'online' hashtable and becomes unusable by Server.
2. After DPD for old lease expires at Server, Server marks the client identity (with new lease) as 'offline' because the code just checks the identity and not the assigned leases. This is problematic because, policies and SAs with the new lease still exist in kernel.
Can someone comment if above 2 are 'bugs' in strongswan?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users