IKEv2 auf dem iPhone: Was in die Felder „Server“, „Remote-ID“ und „Lokale ID“ eingeben

Kurzfassung: Im Feld „Server“ gibst du meist den Domainnamen oder die IP-Adresse deines VPN-Servers ein; bei „Remote-ID“ den Identifikator, der mit dem übereinstimmen muss, was der Server erwartet (oft der im Serverzertifikat angegebene Domainname); und bei „Lokale ID“ die Kennung des Clients, die der Server zur Zuordnung von Regeln nutzt (oft leer lassen oder den vom Anbieter/Administrator vergebenen Benutzernamen/ID eintragen). Die genauen Werte bekommst du immer am besten direkt von deinem Provider oder Admin: Ratespiel sorgt häufig für Fehler bei der Zertifikatsprüfung oder Verbindungsabweisung.

Was bedeuten die IKEv2-Felder unter iOS und warum sind sie wichtig?

Bei IKEv2 (IPsec) tauschen die Parteien Parameter aus und bestätigen ihre Identität. Auf dem iPhone gibt es drei Felder, die oft Fragen aufwerfen:

• Server – die Adresse des VPN-Gateways, zu dem die Verbindung hergestellt wird.
• Remote-ID – „So überprüfe ich den Server“; das ist die Zeichenkette, mit der iOS den Server gegen dessen Identität abgleicht (in der Regel die Daten im Serverzertifikat).
• Lokale ID – „So erkennt mich der Server“; ein Identifikator des Clients, den der Server in Regeln prüfen oder nutzen kann.

Diese Werte werden bei der Authentifizierung abgeglichen. Stimmen sie nicht mit der Serverkonfiguration und dem Zertifikat überein, vertraut iOS dem Server nicht oder der Server lehnt den Client ab. Für ein tiefgehendes Verständnis zur Identifikationslogik und Authentifizierung hilft die Apple-Dokumentation zu IKEv2/IPsec: Apple: IKEv2 Device Management Settings.

Feld „Server“: Domain oder IP – wie finde ich heraus, was rein soll?

Gängige Einträge

• Vollständiger Domainname (FQDN) wie vpn.example.com – am häufigsten genutzt, weil es bei IP-Wechseln und für korrekte Zertifikate am praktischsten ist.
• IP-Adresse – kommt manchmal für schnelle Tests oder bei fehlender Domain zum Einsatz. Für die Zertifikatsprüfung ist aber immer der „Remote-ID“ entscheidend.

Vorbereitende Checks

• Erfrage beim Provider, ob die Verbindung über Domainnamen oder IP vorgesehen ist. Wenn ein Domainname samt Zertifikat bereitgestellt wird, ist die Domain meist die bessere Wahl.
• Falls du eine IP eingibst, prüfe, ob sie dynamisch ist (z. B. bei einer privaten/wechselnden Adresse). Häufige IP-Änderungen können Verbindungsprobleme verursachen.

Sichere Vorgehensweise (leicht rückgängig machbar)

• Wenn du unsicher bist, nutze die vom Provider angegebene Adresse. Bei Fehlern deaktiviere nicht die Zertifikatsprüfung und vermeide unsichere Varianten – besser den korrekten Servernamen erfragen.
• Liegt dir sowohl Domain als auch IP vor, probiere im Feld „Server“ zuerst die Domain; IP dient nur kurzfristig zur Diagnose und wird danach wieder durch die Domain ersetzt.

„Remote-ID“: Der Schlüssel zur Zertifikatsprüfung und typische Varianten

Die „Remote-ID“ ist eine der häufigsten Fehlerquellen, da iOS diesen Wert mit der Serveridentität abgleicht. Beim Einsatz von Zertifikaten ist die Remote-ID fast immer an den im Serverzertifikat angegebenen Namen gebunden.

Typische Werte für die „Remote-ID“

• Domain des VPN (z. B. vpn.example.com) – der häufigste und klarste Fall.
• Identifizierende Zeichenkette (z. B. ikev2.example.com oder gateway-id) – wenn der Provider Adresse und Identität trennen möchte.
• IP-Adresse – manchmal erlaubt, führt aber oft zu Problemen, wenn das Zertifikat für eine Domain und nicht für die IP ausgestellt ist.

Diagnose: Wie erkenne ich die erwartete Remote-ID?

• Kontrolliere die Angaben deines Providers bei den IKEv2-Parametern: gelegentlich ist „Remote-ID“ separat neben „Server“ aufgeführt.
• Falls du eine Profildatei (.mobileconfig) oder Konfigurationsdaten vom Provider hast – dort steht die Remote-ID oft explizit drin. Wenn du manuell einrichtest, solltest du diese Werte möglichst eins zu eins übernehmen.
• Fällt die Verbindung mit Vertrauens- oder Zertifikatsfehlern aus, ist ein häufiger Grund eine Nichtübereinstimmung zwischen Remote-ID und Zertifikatsnamen.

Sichere Handhabung (rückgängig machbar)

• Wenn du in der „Remote-ID“ eine IP verwendest, probiere stattdessen die vom Provider angegebene Domain – und kehre bei Bedarf zurück.
• Gibt es bei „Server“ nur eine IP, aber der Provider nennt für Identifikation eine Domain, lasse bei „Server“ die IP stehen, aber setze für die „Remote-ID“ die Domain ein, damit die Zertifikatsprüfung korrekt läuft.
• Stellt der Provider eine separate „Remote-ID“ (eine Zeichenkette, die nicht der Domain entspricht) bereit, nutze genau diese – auch wenn es ungewöhnlich erscheint.

„Lokale ID“: Wann leer lassen, wann explizit angeben?

Die „Lokale ID“ gibt an, wie du dich auf der Client-Seite identifizierst. In manchen Setups ist sie überflüssig, in anderen essenziell (z. B. wenn der Server Nutzer oder Profile nicht nur über den Benutzernamen, sondern zusätzlich über eine ID unterscheidet).

Typische Varianten der „Lokalen ID“

• Leer – häufig, wenn der Server mit Benutzername/Passwort (EAP) oder Client-Zertifikat auskommt.
• Benutzername – manchmal wird verlangt, dass im Feld „Lokale ID“ der gleiche Login steht, der auch bei EAP verwendet wird.
• Separate Kennung (Zeichenkette) – falls vom Provider festgelegte „Lokale ID“ wie client123 oder user@realm vorgegeben wird.

Check vor Änderungen

• Lehnt der Server die Verbindung ab (nicht wegen Zertifikat), und der Provider erwähnt eine Lokale ID, kann das Feld nicht leer bleiben.
• Funktionieren manche Profile/Nutzer, andere nicht, prüfe, ob die „Lokale ID“ in der funktionierenden Konfiguration gesetzt ist.

Sichere Vorgehensweise (rückgängig machbar)

• Wenn der Provider keine Lokale ID angibt, starte mit leerem Feld. Das lässt sich problemlos rückgängig machen und vermeidet falsche Zuordnungen.
• Gibt es eine konkrete Lokale ID vom Anbieter, übernehme sie exakt (Groß-/Kleinschreibung und Zeichen zählen). Wenn es nicht funktioniert, setze das Feld zurück und frage den Provider nach dem korrekten Format.

Authentifizierungstyp bei IKEv2 auf dem iPhone und warum er mit den IDs zusammenhängt

Unter iOS begegnen dir für IKEv2 im Kern zwei Authentifizierungsmethoden:

• Benutzername/Passwort (EAP) – du gibst deine Zugangsdaten ein, und der Server bestätigt deine Identität. Dabei nutzt der Server fast immer ein Zertifikat, damit dein iPhone sicher verifizieren kann, dass es den „richtigen“ Server erreicht. Hier ist die korrekte „Remote-ID“ besonders wichtig.
• Zertifikat – der Client besitzt ebenfalls ein Zertifikat (vom Admin/Provider ausgestellt). Dann kann die „Lokale ID“ entscheidend sein, um das passende Zertifikat oder Richtlinien auszuwählen, je nach Serverkonfiguration.

Diagnose: Welcher Modus wird verwendet?

• Bekommst du vom Provider nur einen Login und ein Passwort, wird sehr wahrscheinlich EAP verwendet.
• Die .mobileconfig-Datei oder das Zertifikat alleine definieren nicht den Zugangstyp: ein Profil kann EAP-Einstellungen enthalten, während das Zertifikat nur der Serververtrauensstellung dient. Schau beim Provider nach, welcher Authentifizierungsweg vorgesehen ist.

Sichere Vorgehensweise (rückgängig machbar)

• Wechsel die Authentifizierungsart nicht willkürlich, wenn dein Provider gezielt Parameter für einen bestimmten Modus bereitstellt – das führt meist zu Verbindungsabbrüchen durch den Server.
• Falls du denkst, deine Einrichtung passt nicht (zum Beispiel bekommst du ein Zertifikat, versuchst aber mit Login/Passwort zu verbinden), kläre das besser mit dem Anbieter ab und stelle die empfohlene Konfiguration wieder her.

Checkliste zum Abgleich von Zertifikatsname und „Remote-ID“

Praxisregel: Bei der Zertifikatsprüfung muss der „Remote-ID“-Wert dem Namen entsprechen, mit dem der Server im Zertifikat auftritt (in der Regel die Domain). Stimmen sie nicht überein, kann die Verbindung scheitern.

Diagnose-Checkliste (ohne geheime Infos preiszugeben)

Wenn du eine Schritt-für-Schritt-Anleitung zum Anlegen eines IKEv2-Profils unter iOS suchst (sprich: Wo genau klicken), empfehle ich die separate Anleitung: IKEv2 VPN auf iOS einrichten. Hier geht es nur um Bedeutung der Felder und Plausibilitätschecks.

Miniguide für sicheren Umgang mit den Einstellungen

• Veröffentliche keine „Server“, „Remote/Local ID“, Logins, Passwörter, Keys oder Zertifikatsinhalte in Chats oder Screenshots. Bei Bedarf sensible Daten unkenntlich machen.
• Ändere immer nur einen Parameter auf einmal, um den Effekt nachvollziehen und einfach zurücksetzen zu können.
• Deaktiviere nicht die Zertifikatsprüfung und akzeptiere nicht „beliebige Zertifikate“ für schnellen Zugang – das schwächt die Absicherung gegen Servermanipulation.

FAQ: Häufige Fragen zu „Server“, „Remote-ID“ und „Lokale ID“

Kann „Server“ von „Remote-ID“ abweichen?

Ja, das ist ein normaler Fall: „Server“ gibt an, wohin du dich verbindest, während „Remote-ID“ definiert, wie du die Identität des Servers überprüfst. Zum Beispiel kannst du dich per IP verbinden und die Authentifizierung über einen Domainnamen im Zertifikat laufen lassen, wenn der Provider das so vorgibt.

Ich habe nur eine IP: Was kommt bei „Remote-ID“ rein?

Das hängt davon ab, auf was das Serverzertifikat ausgestellt ist und wie das VPN konfiguriert ist. Oft gibt der Provider dennoch eine Domain oder eigene Kennung für „Remote-ID“ an. Sollten solche Daten fehlen, ist es besser, den Anbieter danach zu fragen, statt herumzuprobieren.

Muss ich „Lokale ID“ ausfüllen, wenn ich mich via Benutzername und Passwort einlogge?

In vielen Fällen nicht, das Feld bleibt leer. Einige Konfigurationen verlangen aber explizit eine „Lokale ID“, z. B. zur Zuordnung von Regeln. Liegt dir diese vom Provider vor, nutze sie; ansonsten starte mit leerem Feld.

Warum funktioniert das VPN nach Domainwechsel nicht mehr?

Zwei häufige Ursachen: Die „Server“-Adresse (DNS/Route) hat sich geändert oder der im Zertifikat verwendete Name passt nicht mehr zur „Remote-ID“. Sicherer Weg: vorherige Werte zurücksetzen, dann die neuen Domain-/Remote-ID-Daten vom Provider erfragen und sicherstellen, dass das Zertifikat für den neuen Namen aktualisiert wurde.

Kann man dieselbe „Remote-ID“ für verschiedene Server verwenden?

Ja, wenn der Administrator mehrere Gateways mit derselben bestätigten Serveridentität und passenden Zertifikaten für diese Remote-ID konfiguriert hat. In anderen Setups unterscheiden sich die IDs. Nutze immer den vom Provider angegebenen Wert für den jeweiligen Server.

Wann ein persönlicher Server sinnvoll ist: Wenn du einen stabilen, eigenen VPN-Gateway mit fester IP ohne „Nachbarn“ möchtest und klare IKEv2-Daten (inklusive korrekter „Server/ID“), ist es praktisch, wenn dein Anbieter dir einen individuellen Account gibt und du nur ein Profil verwaltest.

Wann das keine Hilfe bringt: Wenn das Problem falsche Werte sind, die du nicht erhalten hast (wie Remote-ID oder Zertifikat), oder es Einschränkungen durch Netzwerk/Device gibt, ersetzt ein persönlicher Server keine saubere Konfiguration und Zertifikatsprüfungen – du musst weiterhin die korrekten Daten vom Provider verwenden und die Prüfungen aktiv halten.

Passt dein Szenario „ein Nutzer – ein Server“, bietet vpn.how persönliche VPN-Server mit dedizierter IP an; aktuelle Standorte, Protokolle, Preise und Limits findest du auf der Webseite und im Kundenbereich.