[strongSwan] Issues observed with Server leases in road warrior configuration
Kaur, Sumit (NSN - IN/Bangalore)
sumit.kaur at nsn.com
Tue Feb 10 11:11:06 CET 2015
Hi Noel,
Thanks for the reply.
I have another query this time.
Is it possible to restrict that a client get same virtual IP from Server based static pool - always in all scenarios including client reboot?
I simulated a scenario where a client has initially got a virtual IP from server and later it went for reboot without the server getting notified about it.
As soon as the client comes up after reboot, the server assigned a different virtual IP from the static pool to the client.
In this case, since the server was not notified about client going down, the lease was still active at server, and then later when client came up and asked for virtual IP, server gave a different one and also updated the lease with this new assigned Virtual IP.
Is this expected behavior?
I tried putting uniqueIds=yes at both ends. This does not help.
Thanks
Sumit
-----Original Message-----
From: users-bounces at lists.strongswan.org [mailto:users-bounces at lists.strongswan.org] On Behalf Of ext Noel Kuntze
Sent: Thursday, February 05, 2015 12:05 AM
To: users at lists.strongswan.org
Subject: Re: [strongSwan] Issues observed with Server leases in road warrior configuration
-----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-----
_______________________________________________
Users mailing list
Users at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
More information about the Users
mailing list