[strongSwan] Issues observed with Server leases in road warrior configuration
Noel Kuntze
noel at familie-kuntze.de
Tue Feb 10 21:18:07 CET 2015
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello Sumit,
Yes, that is possible by using a database pool. See [1] for information about that.
However, that is the best solution for same IPs including server reboots.
If you use uniqueids=replace, you can force replacement of unique IDs, so
new IKE SAs from a peer replace the old one. That could fix it.
You completely understood the situation that was caused by the unclean
shutdown of the connection.
[1] http://www.strongswan.org/uml/testresults/sql/ip-pool-db/index.html
Mit freundlichen Grüßen/Regards,
Noel Kuntze
GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
Am 10.02.2015 um 11:11 schrieb Kaur, Sumit (NSN - IN/Bangalore):
> 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
>
>
> 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
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJU2md8AAoJEDg5KY9j7GZYqvAP/R/zYcRyLByQc06QruDJpXJ/
Gk1+eRCMlo0wjqThMr1obl/dgol+nK/4Vv6gStBduRcfwof0ZQaiSeOkdoyTw9je
9J054H1s9V/Qzkc294qBLnZihe36ZF/SSixgdvtIlCbdnqTE/7+jJonZwt+DY3w+
tuzcVmRc2xynN3bqXPYgg26aW2spcV7y6fRvJuEHb3TKrHk1YFDn/L6Hq8h18+qC
HOAv9wg9ih/PrOX6tPNSFDyyIPH+I/wTIHUmFAJuuDLYJ3t0u4tLOsuTYq84gJJt
qAwswRm/BYqkN3J3vBgzsPG5F/P2HQHTwrJHfyBRPHf6M3P4HlkQkl3X66yD5Z+3
tknTbR2PZioaYT7qyoXGSyCJBwomx0qwtjXjV6zqo2r9bubUmVH0JpN/2akNW1ZK
K/U38mpefenAbloqEEniZw1CrH3pSQfHOaCdNGZsvNLxroWmOyzFqmUGxcPdSXhk
XooaGWivmIf9FIGbqBMboWMtsF6/Ztkg++6J0GQp/fJ/HYp8jZwkV+bVcf7Z9pGX
seTZuanbVXMrOvQlBDi62DyXgwKXXSOgJi/0LDhNDJgdeWuw1ZxJ9cPgfTnZCVq7
UAsJRAfNZgkxK4NCaooephxnvAxerkgZj6y8XGXd12lTWWYUV2Bz5tQ/Mm/zZcdh
mGfKJuGvyr7OM2oLmJif
=TJ6h
-----END PGP SIGNATURE-----
More information about the Users
mailing list