IKE Identity or Endpoint Address: Do Not Mix Them Up
An FQDN-typed IKE identity is a literal authentication value, not a reverse-DNS lookup. Keep endpoint address, local identity and expected peer separate.
Read a field labelled FQDN identity as a literal string, not as a request for the reverse-DNS name of your public address. In strongSwan's parser it is exactly that, a string, and reading it never resolves it to an endpoint. That fact alone removes the most common distraction when you pick identifiers for a peer. The checks below keep the three values involved from collapsing into one.
A label is not a lookup
Vendor interfaces use words like FQDN and hostname loosely, and the label on a box says nothing about the encoding behind it. An appliance that calls a field Client FQDN may send an FQDN, an email-shaped string or a bare address. Treat the text and the type as two separate decisions, and record both.
Nothing about a literal identity requires DNS. It is a claim the other end checks, not a name the network has to resolve.
Three separate values, written separately
Three jobs sit behind one configuration screen, and merging them is the expensive mistake. One value is the endpoint address, which decides where packets go. Another is the local identity this peer presents, and the third is the identity you expect from the far end before you authenticate it. Write them as three lines in the change ticket, because anything less describes a VPN rather than a relationship.
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
The example identities have to be chosen and authorised as part of the deployment. They are claims that authentication verifies, not credentials that make any peer trustworthy, so a plausible-looking string authorises nothing.
The type is part of the value
The strongSwan identity reference separates FQDN, email-shaped values, IP addresses and other encodings, so the encoding matters as much as the characters. Two devices can accept identical text under different types and still refuse each other. A note that records the value without its type is half a configuration.
Ask the vendor which type the appliance actually sends, and confirm it against a decode rather than the interface label. A guessed type is a mismatch waiting for the next change.
Each side has to satisfy the other
Each side's local identity has to pass the other side's authentication policy. That is not the same as pasting one string into every identity box on both devices, which is the shortcut that produces a configuration nobody can debug.
Certificate authentication adds requirements of its own, because the certificate's identity and the trust conditions sit alongside the IKE identity you typed. An IKE identity match alone does not authorise a certificate peer.
Where DNS matters, and what your version forces
A gateway hostname used for discovery does need working DNS, and that requirement belongs to finding the endpoint rather than to any reverse lookup of a typed identity. Keep the two apart in the ticket, because a discovery failure and an identity mismatch read similarly in a client log and get repaired in different places.
Read the parser for the product and version you actually run before copying syntax that forces a type, since older strongSwan releases behaved differently and other vendors add constraints of their own. When you compare the two ends, hold four things together: expected identity, presented identity, type and the authentication error. That set turns a mismatch into evidence instead of an opinion.