Mobile VPN IKEv2 tunnel drops ~5s after establishment on T45 / Fireware 12.12.1

Mickael70
Mickael70
in Firebox - VPN Mobile User

Hi all,

Running into a very reproducible IKEv2 Mobile VPN issue and wondering if anyone has seen this or knows of a related bug ID.

Setup: Firebox T45, Fireware 12.12.1 (Build 740798), Mobile VPN with IKEv2, Firebox-DB local authentication (dedicated account, member of an IKEv2-Users group). Client: iOS 18, static cellular connection (no network change during tests).

Symptom: Tunnel establishes fully (EAP-MSCHAPv2 auth succeeds, Child SA installed successfully), then gets torn down by the Firebox itself ~5 seconds later. 100% reproducible across 5+ attempts under different config states (with/without PFS, with/without MOBIKE).

Raw iked log for one reproduction (MOBIKE explicitly disabled beforehand via "diagnose vpn", no change in behavior):

15:19:48 iked (...) IPSec SP downloaded for Gateway-Endpoint['WG IKEv2 MVPN' ...] installedSP:3
15:19:48 iked (...) childState(0xaaaafd857508) state change: CREATED ==> MATURE, reason: "Installed Child SAs Successfully"
15:19:48 iked (...) childState(0xaaaafd857508) state change: MATURE ==> DEL, reason: "Free the Child State"
15:19:48 iked Received WG user session xpath:'/toSessionClient/createNotify'

--- 5 seconds later ---

15:19:53 iked (...) Received NO_IN_POLICY XFRM message (type=72) from kernel. ipsec-policy:'WG IKEv2 MVPN'
15:19:53 iked (...) Sent out DELETE[CHILD SA] request message ...
15:19:53 iked (...) ike_config_ipsecPolicy_download_SPs: muvpn case and dynamic_info is empty - 0xfffff0402520
15:19:53 iked (...) recv the deletion request message (proto=IKE, numSPIs=0) from <client>:4500
15:19:53 iked (...) peer deletes ikeSA(...) with "MATURE" state, all of the child SAs under it will be purged implicitly
15:19:53 iked Deleting ikeSA(...) reason="RAS user kicked out"

The childState object is freed ("Free the Child State") in the same second it's marked as successfully installed — before anything should trigger a teardown. 5 seconds later a routine kernel policy check (NO_IN_POLICY) finds nothing and iked can't rebuild the policy (dynamic_info is empty), consistent with that data having gone with the freed object. The Firebox then initiates the Child SA deletion itself, and the iOS client correctly tears down the full session in response.

Ruled out: PFS/DH Group 14 (enabled, no effect), MOBIKE (disabled globally via CLI, identical failure), client-side network change (static connection throughout), known iOS 18 profile issues (SHA1 removed, LocalIdentifier patched per KB).

Found CVE-2026-13368 / WGSA-2026-00023 (use-after-free in Mobile VPN IKEv2, fixed in 12.12.1) but that one's documented as LDAP-auth-specific. We're on Firebox-DB, so likely a related-but-distinct defect in the same code path.

Has anyone else hit this, or knows if it's tracked anywhere?

Happy to share more logs if useful.

Answers

  • Bruce_Briggs
    Bruce_Briggs

    Perhaps this Known Issue?

    Mobile VPN with IKEv2 connections fail on iOS 18 and iOS 26

    https://techsearch.watchguard.com/KB?type=Known%20Issues&SFDCID=kA1Vr00000060IHKAY&lang=en_US

  • Mickael70
    Mickael70

    Hi Bruce,

    Thanks for taking the time to look into this and for pointing me to that article, I appreciate it!

    I actually ran into that exact Known Issue (article 000031210, empty LocalIdentifier in the generated .mobileconfig) when I first set up this tunnel, and I already applied the workaround back then (non-empty LocalIdentifier value). So that fix has been in place on my profile from day one.

    It doesn't look like the same bug though. That Known Issue leaves the client stuck on "Connecting..." forever and the session never gets established (payload(IDi)'s size is smaller than the minimal value(8 < 10)). In my case the tunnel actually establishes fine, the Child SA reaches MATURE, and then the Firebox itself tears it down about 5 seconds later with a NO_IN_POLICY from the kernel. The raw iked log in my original post shows the childState object getting freed right after a successful install, which seems to be what triggers the whole thing.

    Still, thanks for the pointer. The article now lists two internal WatchGuard Tracking IDs I didn't have before (FBX-28074 and FBX-30445), which at least tells me this general area of the IKEv2/iOS code has more than one open issue on their side. I'll mention those in the support ticket I'm opening for this specific drop.

    Thanks again for chiming in!

  • Bruce_Briggs
    Bruce_Briggs

    If you have an active support license on your firewall, consider opening a support case on this.

Categories