Hello William
You’re right, it is confusing! I believe the source of the confusion comes from the use of the fqdn keyword.
The use of FQDNs in IKEv2 profiles doesn’t require DNS resolution because these FQDN values simply serve as static identifiers rather than actual DNS queries.
The match identity remote fqdn command compares the peer’s declared identity against a preconfigured string. Peers exchange identities during IKEv2 negotiation as raw strings, not IP addresses. This FQDN value simply acts as an authentication fingerprint. Both devices must have matching configurations for local identity (e.g., identity local fqdn R1.NWL.LAB) and remote identity (e.g., match identity remote fqdn R2.NWL.LAB).
The approach is analogous to using pre-shared keys (PSKs) - both ends need identical configurations, but no underlying DNS infrastructure is required. This makes it suitable for static site-to-site VPNs where IP addresses might change but organizational naming remains consistent.
For the command, you can actually input whatever you want! For example you can issue the following command:
match identity remote fqdn helloworld
If the string matches, it will work. There are other options to use such as email, domain, or key ID. See this command reference for more details.
So these values simply serve as labels, but it is useful to have them use meaningful values rather than some dummy value like helloworld that I mentioned before. Does that make sense?
I hope this has been helpful!
Laz