Results 1 to 4 of 4
  1. #1
    Untanglit
    Join Date
    Jul 2012
    Posts
    24

    Default Tunnel drops at IKEV2 Phase 1 renegotiation; "break-before-make"?

    I'm chasing a problem with a new provider and am using IKEV2. The Phase 1 reneg happens every 8 hours, and my users get kicked when it does. I didn't have this problem on an old provider using IKEV1. There are no errors in the ipsec log except "received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding" which I doesn't seem to be an actual issue, or not related to mine issue anyway.

    Came across this article talking about "make-before-break" support in IKEV2 being off by default, and indeed when I look at the config files mentioned I see that it's off. Could this be the source of my problem?

    https://wiki.strongswan.org/projects...ki/ExpiryRekey

  2. #2
    Untanglit
    Join Date
    Jul 2012
    Posts
    24

    Default

    Nothing at all from anyone? No one has encountered this?

  3. #3
    Untanglit
    Join Date
    Jul 2012
    Posts
    24

    Default

    I've also been working this through my limited support because, while I am paying for the IPsec module, the rest of my Untangle is the non-paid version, but Shawn with support has been really helpul in trying and I appreciate his and the team's effort.

    The silence here on the forum is surprising. I at least expected something along the lines of "you're an idiot and you know nothing about which you speak".

    Support has finally told me the tunnel dropping during Phase 1 reauth is WAI and they won't cosign my crazy schemes, of course. Since I've exhausted those options I'm going to post an epilogue here, in the hopes that either it triggers someone's helper instincts, or UT IPsec developers read it and think "hey, maybe that's a good idea".

    I did a deep dive on Strongswan and through conversations with the other side of the tunnel (and their Cisco support) I am lead to believe "make_before_break" is the solution I am looking for. As long as the other side supports it, the child SA should be rebuilt without a disruption in the tunnel (better support for actual non-disruption in 5.5.3 but, whatevs, since it doesn't work at all now). On UT, the key config file is written with a warning that it is managed by Untangle IPsec service and changes will be rewritten. Unless there's a backdoor way to enable the flag in charon.conf, I don't have access to it. UT's version of strongswan.conf (which is where the UT rewrite warning is) is missing a line from the default that would load charon.conf (and which appears to be unused because of an omitted Include statement). Interesting to note that charon.conf does NOT have that rewrite warning.

    There's a little more to it, but the detals on the default strongswan.conf and the Include which would load charon.conf are here: https://wiki.strongswan.org/projects...gswanDirectory

    In the end I guess I would hope that UT would allow maybe an "Advanced" configuration area where the items in charon.conf are toggleable.

    More details on the rekey issue are here: https://wiki.strongswan.org/projects...ki/ExpiryRekey

    It think that a disruption of the tunnel traffic (causing user data loss), should be considered a bug.

    In the meantime I'm going to roll with a longer Phase 1 lifetime and restart it during the wee hours so that the reauth happens during a time users shouldnt' be on. That will kick the problem properly down the road unless I have to restart the tunnel during working hours for a different issue.

    I'm happy to answer any questions, or learn something new that I haven't found through this process.

  4. #4
    Untangle Ninja
    Join Date
    May 2008
    Posts
    1,231

    Default

    Sorry for your problems but I know nothing about ipsec. You might create a feature request here.

    https://untanglengfirewall.featureupvote.com/

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2