Same IKEv2 identity on two iPhones? They take turns connecting
One profile copied to two devices gives the gateway one peer instead of two. Watch the peer table fill and empty, then issue a value per device.
Two phones, one profile, and a pattern that looks supernatural until somebody watches the gateway. One device holds the tunnel, the second connects, and the first loses it within seconds. The first reconnects and the second drops. Battery saving, Wi-Fi roaming and carrier NAT all get blamed, while the actual cause sits in a text field that was copied along with everything else. IKEv2 identifies a peer by a name, and both phones are presenting the same one.
Identity is the key the server stores you under
Inside an IKEv2 exchange each side states who it is: the initiator sends a local identifier, the responder answers with its own, and the responder also checks the identity the initiator claimed against policy. The gateway keeps its state per identity rather than per device, because a device is not something it can see. Two phones with one identifier therefore arrive as one peer, and the second exchange has to overwrite the first. The trouble only appears while both are in use, which is why a single-phone test never reproduces it.
Nothing about this is a bug in the client. The client sent exactly what the profile told it to send.
What the collision looks like from the gateway
Watch the peer list while both phones are awake and in use. A collision shows a single entry whose address changes as the phones swap, with the counter of active sessions never reaching two. On-demand teardown looks different, and telling them apart takes one observation rather than a theory.
| Observation | Shared identity | Idle teardown |
|---|---|---|
| Peer entries while both are awake | One, with a changing address | One per phone, or none |
| What triggers the drop | The other device connecting | Time without traffic |
| What restores it | The other device disconnecting | Any app needing the tunnel |
Write both events down with timestamps while it happens. A drop that lines up with the other handset connecting points at the identifier, and a drop that arrives one idle interval after the last packet points at a timer.
Where the duplicates come from
Exporting one working configuration and editing only the server address produces a second file with the first file's identity still inside it. That is the ordinary path to this failure, and it usually happens while onboarding a small group in a hurry.
The field names make it easy to miss. The remote identifier names the gateway the phone expects, and copying it is correct. The local identifier names this handset to the gateway, and copying that value is the whole problem.
Issue a value per device
Use something unique to the handset and stable for its lifetime, such as the device identifier from the inventory or a value your management system generates per enrollment. A department label, a shared service account name or the user's email address all collide as soon as that person has a second device.
Generate the payload per device rather than distributing one file. Record which value belongs to which handset, so a replacement does not restore the old profile and land the new phone straight back in the same collision.
Check the server side as well. A gateway that maps the identity to a fixed tunnel address can still collide when two different identifiers receive the same assignment, so confirm the pool has room and that assignments are not pinned per user.
Verify with both phones awake
Connect the first, reach a private resource, then connect the second and leave both idle for a minute. Both sessions should persist and the peer list should show two identities. Then lock and unlock each phone to confirm the idle case still behaves.
If a single session still drops once a day with nothing else connecting, the identity is no longer the suspect. Move on to idle timers and server session limits instead of editing the profile again.