[strongSwan] MOBIKE task got stuck Strongswan version 5.3.2

[Simon Chan]

Hi Tobias,

After customer added roam_events = no in config file,
problem still occurs on most of the tunnels.
It would seems MOBIKE tasks are not caused by interface up/down.
Can you tell what events can trigger activation of MOBIKE task?

I saw these in customer's syslog:

   - sending DPD request
   - generating INFORMATIONAL request 0 [ N(NATD_S_IP) N(NATD_D_IP) ]
   - no route found to reach peer, MOBIKE update deferred

I cannot reproduce such exchange in my lab. I got these logs:

   - sending DPD request
   - activating IKE_DPD task (may come from my own debug prints)
   - generating INFORMATION request 0 [ ]
   - sending packet: from <server_add> to <client_addr>

Thanks,

Simon



On Fri, May 5, 2017 at 2:20 AM, Tobias Brunner <tobias at strongswan.org>
wrote:

> Hi Simon,
>
> > 1. Any guesses on how MOBIKE task get stuck and won't timeout? Should
> > there be on-going re-tries?
>
> Read the log.
>
> > 2. I think charon is still sending keepalive messages to the peers with
> > MOBIKE task active, but no DPD is sent. This behavior seems to create
> > the situation that tunnels stay connect but they are really dead long
> ago.
>
> Could be the daemon thinks there is no valid path to reach the peer, so
> it deferred sending any messages until the network connectivity changes
> (again check the log for details).
>
> > 3. Following Q2, DPD won't do any good because the MOBIKE task seems to
> > have higher priority then delete. Is this behavior fixed in 5.5 recently
> > (issues/1410)?
>
> That issue is related to IKEv1.  The idea behind preferring MOBIKE tasks
> over others is that without a valid path to the peer there is no point
> in sending other messages and if the peer can't be reached, the MOBIKE
> exchange, whether it is an update or a DPD, will trigger the DPD action
> anyway.
>
> > 4. I need to support remote devices doing MOBIKE switch but I don't want
> > the VPN server in the office to perform MOBIKE switch. It is futile.
> > There is no secondary internet interface to switch to. Chaos ensure when
> > charon tries to find alternate paths on a 1000 tunnels.
>
> The MOBIKE task does not necessarily mean that this is an actual MOBIKE
> update.  With MOBIKE enabled between two peers DPDs are also handled by
> these tasks.
>
> > Can development team
> > members point out where I can tweak the source code to silently ignore
> > MOBIKE jobs? If I put mobike=no in ipsec.conf I think remote peers won't
> > be able to do MOBIKE switch.
>
> If the MOBIKE task is actually triggered by a network change you can
> avoid that by disabling charon.plugins.kernel-netlink.roam_events.
>
> Regards,
> Tobias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170528/0a52ba42/attachment.html>