[strongSwan-dev] Is this a leak in virtual IPs, in ike_sa.c clear_virtual_ips

[SM K]

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 <sacho.polo at gmail.com> 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 <tobias at strongswan.org>
> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150406/bb681342/attachment.html>