[strongSwan] Issues observed with Server leases in road warrior configuration

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Kaur,

That is caused by your configured uniqueness policy.
Try uniqueids=replace in config setup section of ipsec.conf

Also, strongSwan will never assign an active lease twice.
That would cause ambiguous routing and is disallowed by the kernel and sanity.

If strongSwan thinks the client disconnected, then it _is_ disconnected. The server has
the full interpretational sovereignty over this. If a client thinks it is still connected,
then something went awfully wrong on the client side and you should see if
you can use dpd or a newer client software.

strongSwan handles the complete IKE negotiation with a client
and installs the policies by itself. The kernel will not allow duplicate policies.
It will reject installing such policies that are identical to already existing ones.

In your roadwarrior setup with a virtual IP, the policy covers the virtual IP and the 40.0.0.1/32 IP.

Mit freundlichen Grüßen/Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 04.02.2015 um 14:59 schrieb Kaur, Sumit (NSN - IN/Bangalore):
> Hi,
> 
> When configuring road warrior as below in  strongswan version 4.3.6, we observe an odd behavior w.r.t the Server leases.
> 
> 
> Server :-
> 
> conn r1~v1
>          left=40.0.0.1
>         right=%any
>         leftsubnet=40.0.0.1/32
>         rightsourceip=99.0.0.0/30
>         authby=secret
>         leftid=40.0.0.1
>         rightid=%any
> 
> 
> Client :-
> 
> conn r1~v1
>         left=25.0.0.2
>         right=40.0.0.1
>         leftsourceip=%config
>         rightsubnet=40.0.0.1/32
>         authby=secret
>         leftid=25.0.0.2
>         rightid=%any
> 
> 
> 
> The Server assigns all IPs from its pool to connecting client r1~v1, if r1~v1 connects to it several times, but maintains only the latest virtual ip address entry in the lease. The client has multiple xfrm policies corresponding to all virtual IPs assigned.
> 
> # ipsec leases
> Leases in pool 'r1~v1', usage: 1/3, 1 online
>          99.0.0.1   online   '(vr*)25.0.0.2'
> 
> # ipsec leases
> Leases in pool 'r1~v1', usage: 1/3, 1 online
>          99.0.0.2   online   '(vr*)25.0.0.2'
> 
> 
> 
> Deleting r1~v1 connection from client, disables the lease from the server, but the client does not delete all virtual IPs and has the respective xfrm policies still in kernel.
> 
> # ipsec leases
> Leases in pool 'r1~v1', usage: 1/3, 0 online
>          99.0.0.2   offline   '(vr*)25.0.0.2'
> 
> 
> Client side :
> 
> # ip xfrm policy
> 40.0.0.1/32[0] 99.0.0.2/32[0]
>         upspec 1 dev (none) uid 0
>         in  allow index 0x00001208 priority 1678 share any flags 0x00000000
>         tmpl-1:
>           40.0.0.1 25.0.0.2
>                 esp spi 0(0x00000000) reqid 4 tunnel
>                 level required share any algo-mask:E=32, A=32, C=32
>         fpid 0x000000a4
>         policy type main
> 99.0.0.2/32[0] 40.0.0.1/32[0]
>         upspec 1 dev (none) uid 0
>         out allow index 0x00001201 priority 1678 share any flags 0x00000000
>         tmpl-1:
>           25.0.0.2 40.0.0.1
>                 esp spi 0(0x00000000) reqid 4 tunnel
>                 level required share any algo-mask:E=32, A=32, C=32
>         fpid 0x000000a3
>         policy type main
> 
> 
> It is possible in this scenario, that server gives 99.0.0.2 virtual ip address to a new connection(it assumes 99.0.0.2 is offline), but 99.0.0.2 is still present on a previous connection.
> 
> 
> The above behavior seems to be incorrect. Ideally, at first place itself, server should not assign different virtual IPs to the same client even if the client tries to connect to it several times.
> 
> Can someone provide inputs on this.
> 
> Thanks
> Sumit
> 
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJU0mZrAAoJEDg5KY9j7GZYjGwP/iRJxOwXDu7Q1W4t8YrXOmx9
5076d9cfDr26K/AaQ4SWQXgIrGwireWkmdR96zBT4pOp7KjNYUG36mfdehAFlbvT
6gfkSw2I0hf31rJ684Dfk/DzrxcnceYSxJ6sebib4gYSwHQTXb5kKNml4i6A3hKu
wQW7V0u7x3ZcG9GtXSV+tXJLLNK2UjBS0MU6lA/lxuAC7Ty9NNj0PRw0fymhrBd0
2ZQ1CV69oyQtY9WQXDzKDZB6tVI+SCQeRe0EZtKs08dVnUsjvM0sprQH6p2svAxA
iZgyUn4+XFXwebtHgna+ONMH/kbusLsxSpXslqvp8Nv+b9pP9n0DM98LocYI1HbO
LLj2NZv55lXEihgF5R7RgBBDO5Y8W3yfyVlyOd8pP67h9DWvj+RWfp5E5FlX9gvU
WvC3q9RphlnHaoQa9FssfShXZiLzCPD6voOrFAe/ZZ2Tx8mCgPn1JBNcpL1BFDAU
1RWQoKyhXZd1Svq5IeBK9DYK/fPn/LMBgDjpjurg9taF9X04tlDuUYZWu8U+9qaA
KG+8q2bxQKGd9VIl9nQyPEQaHnt3hfSxzyAM8aV03WLRnx6QJzpVCgkecQ3mXiqQ
LCxBDVrzRzfT1GfsWv0vHSERql78ToEx+Jm/66zMDnbs2M5e4Y1StgcLkflJlXCu
T8QRv/xnuqVEjXcku1eF
=slQH
-----END PGP SIGNATURE-----