Incoming IPsec Peer Matches No Profile? Check Four Fields

Your peer reports the tunnel is up, your side shows no security association, and the configuration file clearly contains a matching connection name. Those three statements can all be true. An incoming negotiation is matched against the running configuration, using the peer's address, the identity it presents and the traffic it proposes. A file on disk that was never loaded, an identity that does not match the expected value, or a selector pair that is off by a prefix will each produce silence. Walk the four field groups in the order the responder does.

Start from the packet, not from the file

The responder receives an IKE request, looks for a definition that can accept this peer, and then continues with authentication and traffic selection. If no loaded definition matches at the first step, the negotiation ends before any useful error reaches the user.

That is why "the config looks right" is not evidence. The question is what the running service has loaded and which entry it selected for this attempt. A status listing answers that in one command, while an editor buffer answers a different question. Check the listing before you change the file again.

Field group one: the definition that is actually loaded

Check the running state with the tool that owns the daemon: a status command listing loaded connections, not the editor buffer. Confirm the entry you expect is present, is enabled for the startup behaviour you intend, and was loaded after your last edit. A saved file that has not been reloaded is the most common cause of "I fixed it and nothing changed".

Also confirm which file the service reads. Distributions differ, and a connection written into the wrong include is silently ignored rather than rejected. If the status listing does not show your entry at all, suspect the include path before you suspect the syntax.

Field group two: endpoints are not identities

The address the peer connects from and the identity it authenticates with are separate fields. A hostname, a distinguished name, a key ID and an address can all serve as an IKE identity depending on the configuration, and they do not have to look like the public address at all.

Endpoint matching may also involve a NAT view: the address seen on the wire can differ from the address the peer believes it has. In libreswan's connection model, left and right are labels for the two participants rather than a fixed local and remote order, which is why copying a working config from another site and swapping the addresses is not a reliable translation.

Write down both sides' expected identity and the credential that validates it. If those two lines disagree, no amount of address tweaking will produce a match.

Field group three: the traffic being protected

Selectors describe the inner source and destination ranges, their address family, and any protocol or port restriction. A proposal for one host address is not the same request as a whole subnet, and a responder configured for the subnet may decline it or narrow it.

When the two ends disagree, compare the intended flow from both viewpoints instead of widening every selector to make something connect. Ask each administrator for the flow they believe they are protecting, then diff the two answers. The mismatch is usually a host prefix on one side and a subnet on the other. A tunnel that matches because it now protects everything is a different security decision, and one that nobody approved.

Field group four: you are reading one implementation

Libreswan, legacy Openswan and strongSwan have different management tools, different configuration syntax and different matching order. A working example from one says nothing precise about another's profile-selection priority or its error wording, so verify with the documentation for the daemon on this host.

Correlate one attempt end to end: the initiator's source address, offered identity and proposed selectors, against the responder's selection message and the loaded entry it names. Zero encapsulation and decapsulation counters only say that the observed associations have not carried those packets; they do not name the endpoint that rejected the proposal or prove that a matching entry existed at that moment.

After a coordinated correction, confirm the selected profile and association, then exercise the actual permitted service and its reply path. A profile match enables negotiation, and negotiation is not the last access check.