| Previous | Next |
| ERROR_IPSEC_IKE_RATELIMIT_DROP | ERROR_IPSEC_IKE_AUTHORIZATION_FAILURE |
ERROR_IPSEC_IKE_PEER_DOESNT_SUPPORT_MOBIKE
ERROR_IPSEC_IKE_PEER_DOESNT_SUPPORT_MOBIKE identifies a capability mismatch for MOBIKE, the IKEv2 mobility and multihoming extension. MOBIKE lets the outer addresses associated with an IKE SA and a tunnel-mode IPsec SA change when a client roams to another interface or a multihomed host moves traffic to a different path.
This status is about the outer transport path, not the virtual address inside the VPN. A peer can support ordinary IKEv2 while not advertising the MOBIKE_SUPPORTED capability. Whether the session may continue without MOBIKE depends on the effective connection policy and on whether mobility is actually required for that deployment.
What to verify
- Inspect the IKE_AUTH exchange for the
MOBIKE_SUPPORTEDnotification rather than inferring capability from a VPN client brand or version. - Determine whether the connection is expected to survive Wi-Fi, cellular, or public-address changes. If it is not, a profile that requires MOBIKE may be unnecessarily strict.
- Confirm that both peers use IKEv2 and that NAT-traversal traffic on UDP 4500 is permitted where the implementation uses it.
- Separate this from a certificate, EAP, or address-pool problem: those failures occur in different parts of the exchange.
For example, strongSwan documents MOBIKE as enabled by default for IKEv2 connections and uses UPDATE_SA_ADDRESS when route or address changes require a new outer path. The actual compatibility decision, however, must be taken from the trace and active policy of the affected peers.
References
- RFC 4555: signaling MOBIKE support
- strongSwan: MOBIKE behavior and UDP 4500
- strongSwan: Windows IKEv2 interoperability
Looking for a different code? Search another status or error code.
