iPhone VPN Remote ID: What the Field Actually Means

You are in Settings, adding an IKEv2 configuration, and two fields want text nobody gave you: Remote ID and Local ID. Neither is your username, and neither is a second copy of the Server field. Remote ID is the identity the gateway must prove to your iPhone; Local ID is the identity your iPhone claims to the gateway. Get either wrong and the tunnel dies after the server has already answered, which is why the failure looks like a password problem but is not.

Where the fields sit in iOS

Open Settings > General > VPN & Device Management > VPN and add an IKEv2 configuration. Under Authentication you pick User Name or Certificate, and only then do Remote ID and Local ID appear as free-text boxes. They are identifiers, not addresses: iOS carries them in the IKE_AUTH exchange, where IKEv2 calls the initiator identity IDi and the responder identity IDr.

After you save, iOS folds the configuration into a single row and stops showing the values. Tap the info button or open the profile again before you conclude the fields are empty. A configuration pushed by MDM may grey them out entirely, which changes who is able to fix the problem.

Remote ID is the gateway's name

This is the value your iPhone expects the server to prove. With certificate authentication it is compared against the name in the server certificate, usually the subject or a subjectAltName entry. If the certificate is issued for vpn.example.com, that hostname is the Remote ID, even when you reach the box at a bare IP address.

That mismatch is the classic failure: packets arrive, the server answers, and the connection still collapses because the identity in the certificate does not match what the profile demanded. Pointing the Server field at the raw IP does not help, and on many gateways the server simply stops responding to an identity it cannot match.

The gateway has a matching setting. A strongSwan server sends its own identity with leftid and can restrict the client identity with rightid; if the two sides disagree about the string, IKE_AUTH fails in both directions. Ask the operator which identity the certificate was issued for instead of transcribing the URL from a browser bar.

Apple documents the payload keys as RemoteIdentifier and LocalIdentifier in its IKEv2 settings reference. Both are plain strings, so case and a trailing space can matter.

Local ID is what your iPhone claims

With User Name authentication, the username and password are checked by EAP, and Local ID is a separate IKE identity that some gateways also enforce. A gateway may require Local ID to equal the username, to be an email address, or to match an entry in its connection policy; others ignore it. Leaving it blank is safe only when the operator says so.

With Certificate authentication, Local ID should match an identity the gateway accepts for that client certificate, often the certificate common name or a value mapped to a device record. Copying a colleague's profile copies their identity too. At best the gateway logs the wrong device; at worst a per-device policy rejects you.

The trap is assuming blank means no identity. Do not fill an empty field with your email address just because it looks unfinished. Confirm the intended value and enter it exactly as given.

A five-minute check before you save

Work through these in order; the first step that fails is the one to fix.

1. Get three strings from the operator: the name in the server certificate, the expected Local ID, and the authentication method.
2. Match the authentication method. Remote ID and Local ID do not replace a username and password, and a certificate profile will not accept a password.
3. Type the values exactly, including case, with no trailing space.
4. Keep certificate validation on. Installing an unrelated root certificate to silence a warning hides a name mismatch instead of fixing it.
5. Test on cellular data, not office Wi-Fi, so a captive portal or split DNS does not masquerade as an identity problem.

Read the table from the top. A timeout on the Server row means the identity fields were never tested, so stop there. An error that appears only after the server has responded is almost always a Remote ID or Local ID mismatch.

Errors that point at the wrong field

A message such as "User authentication failed" is about credentials or EAP, not Remote ID. A certificate warning is about the name in the certificate, which is where Remote ID and the Server field meet. "The VPN server did not respond" usually means UDP 500 and 4500 never completed, or NAT traversal failed, and no identity was compared at all.

On the gateway side, identity failures look different: the peer is rejected during IKE_AUTH, or the log names the ID the client sent and says it matches no connection. That log line is the fastest way to settle the argument, because it shows the exact string the phone sent.

Resetting a password will not repair an expected server identity, and changing Remote ID will not repair a wrong password. Separate the stage first, then edit the field that belongs to that stage.

When the profile is managed

If the fields are greyed out, the configuration came from MDM and the phone is not the place to fix it. The VPN payload carries the identifiers, so the correct change is in the profile on the management server, followed by reinstalling it on the device.

Check Settings > General > VPN & Device Management to see whether the profile is managed and who signed it. If you cannot remove it, you cannot edit the identifiers locally, and building a second local profile only creates a conflicting configuration.

Before you close Settings, write down the three strings you entered and where they came from. Next time the tunnel fails, compare the gateway log's received ID against that note: if it differs, you are looking at the field, not the password.