[strongSwan] MOBIKE

[Patricia de Noriega]

Hello,

I've detected some issues when using MOBIKE and I'd want to ask you about
them.

In my experiments I send UDP traffic by means of C sockets. When I disable
the main interface it occurs what you can see in "cap1.png". I suppose after
the datagram 6589 the interface goes down (the default route is deleted) and
then it is introduced some delay until the socket detects that there is no
route from the main interface and try to send the next datagram (6589) from
the secondary interface. After that, MOBIKE detects the same and starts
first, a liveness test from the secondary interface (datagrams 6592 and
6593) and then starts the address update.

In "cap2.png" I perform the same experiments but the firewall is activated
to avoid send data packets outside the tunnel. In that case, it is send one
packet through the tunnel (datagram 793) between the liveness test and the
handover procedure.
Can this packet be tunneled at that point? are initiator and responder
updating the SAs after the liveness test? I think this packet should not be
received through the tunnel until the handover process ends.

Is the return routability check activated by default? by who?

Best regards.


On 29 July 2011 18:07, Tobias Brunner <tobias at strongswan.org> wrote:

> iptables -A INPUT  -m policy --dir in  --pol ipsec --proto esp -j ACCEPT
>> iptables -A OUTPUT -m policy --dir out --pol ipsec --proto esp -j ACCEPT
>>
>> Thus no plaintext packets should leave the VPN endpoint.
>>
>
> That's probably the best solution for now.  The problem with the virtual IP
> approach is that the route has to be changed to the new interface, even when
> the IP is bound to a dummy interface.  And there we currently have the same
> delete/add race condition we had with the policies.
>
> Regards,
> Tobias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110825/5087b1d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cap1.png
Type: image/png
Size: 110241 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110825/5087b1d6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cap2.png
Type: image/png
Size: 73587 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110825/5087b1d6/attachment-0001.png>