-----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: [email protected] > [mailto:[email protected]] On Behalf Of ext Noel Kuntze > Sent: Thursday, February 05, 2015 12:05 AM > To: [email protected] > 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 > > [email protected] > > https://lists.strongswan.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > 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----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
