Five address roles in an IPsec profile, and which one is wrong
Endpoint, identity, protected subnet, gateway source and next hop each answer a different question. Match the symptom to the field first.
Five different jobs get an address in a typical connection definition, and they do not have to agree with each other. Administrators get stuck because a sensible instinct, make all the fields point at the same host, is wrong for at least three of them. The way out is to name the symptom first and then look at the one or two fields that could produce it.
The five jobs, in the order they matter
The transport endpoint is where the IKE exchange is delivered. The authenticated identity is the name each side proves, and it is checked against policy rather than against a routing table. The protected subnets are the selectors that decide which inner traffic belongs in the tunnel. Then there is the source used when the gateway itself starts a conversation, and finally the underlay next hop for reaching the peer.
Participant labels such as left and right are conventions for two sides of a connection, not synonyms for local and remote. Read the manual for the implementation that is actually installed before assuming a key means what a different product meant by it.
| Job | Typical key | What fails when it is wrong |
|---|---|---|
| Transport endpoint | left, right | No IKE exchange at all |
| Authenticated identity | leftid, rightid | Exchange starts, peer rejects it |
| Protected subnets | leftsubnet, rightsubnet | Tunnel up, traffic not selected |
| Gateway source | leftsourceip, rightsourceip | Only gateway-originated flows fail |
| Underlay next hop | leftnexthop, rightnexthop | Peer unreachable from this host only |
Decision one: nothing establishes
When no exchange appears in the logs at all, the endpoint is the first suspect: a wrong address, a filtered path, or an interface the daemon is not listening on. Move to the identity fields only after a handshake is visible, because identity is judged inside the exchange, not before it. A filtered path and a wrong address look identical from the client, so check the listening side before editing anything. Confirm the daemon is bound to the interface you expect, because a service listening on one address looks exactly like a blocked path.
A public address observed through translation is not the same thing as the identity a peer proves. Changing an address to match what a packet capture shows at the far end is a common and wrong correction.
Decision two: the tunnel is up and traffic dies
Selectors decide what enters the tunnel, and a mismatch here produces a connection that negotiates successfully while the application still fails. The far side has to name your protected range as its remote range, which is exactly where reversed values creep in.
Read both configurations side by side before editing. The local range on one host is the remote range on the other, and a single swapped pair explains a tunnel that carries nothing. Narrow the pair before touching the keys: one subnet inside the tunnel and one outside tells you whether the selector or the routing is at fault.
Decision three: only the gateway's own traffic fails
Traffic forwarded for clients can work perfectly while a request the gateway starts itself fails, because that flow has no client source to inherit. The preferred-source setting exists for this case, and it is not source translation: it chooses a source address rather than rewriting one.
An application that explicitly binds another address can override the preference, so confirm the packet's actual source before concluding the setting is ignored. Capture on the gateway's own interface rather than trusting the configuration's intent.
Next hop is a local instruction
The underlay next hop tells this host how to reach the peer, and the far side has no need for the same value. Treating it as a shared setting, or hard-coding a default gateway, breaks the moment the route changes or a second path appears.
Some implementations offer special values here. Whatever the manual lists for the installed version is the only safe answer, and the local route table is the evidence that it worked. When a peer is reachable by name but not by address, that mismatch is the finding, not a detail to work around.
Read the profile from both ends
Reversing the roles on paper is the fastest review there is: swap the protected ranges, keep each side's own next hop, and keep each side's own identity. Anything that does not survive the swap is probably assigned to the wrong job.
Then test one flow per role: peer-to-peer reachability, an inner client flow and a gateway-originated request. Three tests tell you which job is misassigned without opening the configuration again. Add the result to the ticket next to the field you changed, because the next engineer will meet the same profile.