Hi Tobias, I tested with the fix from https://wiki.strongswan.org/issues/807. There was one small problem with it for me. When the iOS device sends a modecfg request to strongswan, it requests the vip %any. This causes the assign_migrated_vip function to not find the already assigned VIP and hence strongswan ends up assigning a new VIP from the pool. I added a check for requested->is_anyaddr(requested) and that worked for me. I don't see the leak anymore and the same vip that is given out in the push message is given out in the pull reply. I don't know if this is a proper fix, but it worked for me.
regards, sk On Fri, Apr 3, 2015 at 1:02 PM, SM K <[email protected]> wrote: > Hello Tobias, > > Thank you for you reply. I completely understand that this is an iOS bug > and strongswan was doing the right thing. However because we cannot change > the client (iOS), we have to handle this in strongswan. I took the fix you > mentioned in [3] and ported it to our code base and it fixed the problem. > We will try to move to 5.3.0 as soon as we can. > > As regards to the xauth-noauth plugin, when we tested with it, we still > ran into the same problem. We do turn off xauth in the iOS profile > installed on the phone, but iOS has a bug in 8.x version of their software > and they do not honor it. There is a bug against apple for this, but I am > not sure if this has been fixed. But we still ran into the same problem > with the modecfg when we used the plugin. > > It looks it is expcted that clear_virtual_ips does not release the vips to > the pool and is not a bug. Thanx for the clarification. > > regards, > sk > > On Fri, Apr 3, 2015 at 1:50 AM, Tobias Brunner <[email protected]> > wrote: > >> Hi, >> >> > I am having a problem with the virtual IP pool being exhausted when >> > connecting from an iOS device. I have the fix in >> > https://wiki.strongswan.org/issues/764 , but I am seeing the issue >> > mentioned by one of the users on the bug. >> > >> > The leak is because the modecfg defined for the iOS device connection is >> > push, while iOS actually uses modecfg=pull. However, for an actual iOS >> > device, it seems that I have to define modecfg=push, otherwise the iOS >> > device connection fails (or hangs). >> >> As discussed in the follow up comments in #764 [1], this looks like a >> client bug (the client clearly does ModeCfg in pull mode, and the Apple >> docs [2] also don't mention a change to push mode if XAuthEnabled is set >> to 0 in the configuration profile). >> >> Also, you should consider an upgrade to 5.3.0 for iOS devices as you >> will run into [3] otherwise. And the fix for that issue (together with >> other changes in 5.3.0) might actually help in this case (see below). >> >> > We cannot use xauth and using the >> > xauth-noauth plugin also did not work in this case. >> >> Why not? It was specifically added for iOS devices. >> >> > While debugging this problem, I noticed that the build_reply function in >> > mode_config.c clears the ike_sa's virtual IPs before allotting new ones. >> > The function clear_virtual_ips is called on the ike_sa to do so. But >> > this function frees the VIP but does not release them back to the pool. >> > Is this a bug? >> >> Not really, it is caused by an incorrect config and client behavior >> (push mode "needed", while the client then still does pull mode). With >> 5.3.0 existing VIPs on the IKE_SA are reassigned during ModeCfg, as this >> is required during reauthentication. So this might help here too, as >> the VIP acquired in push mode will be reassigned in the pull mode >> exchange that immediately follows. >> >> Regards, >> Tobias >> >> [1] https://wiki.strongswan.org/issues/764#note-12 >> [2] >> >> https://developer.apple.com/library/prerelease/mac/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html#//apple_ref/doc/uid/TP40010206-CH1-SW29 >> [3] https://wiki.strongswan.org/issues/807 >> >> >
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
