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 <[email protected]> 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 > >
