When IKEv2 returns TS_UNACCEPTABLE, compare the real subnets

Read TS_UNACCEPTABLE as a coverage disagreement, not as a corrupt profile. The gateway is saying that the two peers could not agree on which addresses this tunnel may carry. The IKE SA can already be up at that moment, which is why a client may look connected with no child SA behind it. Once you frame it that way, the work becomes mechanical. Write down both sides' intended prefixes, compare them in one direction, and narrow until they intersect.

Write the intended pairs down first

Before touching configuration, list four values: the initiator's source range, its destination range, and the same pair seen from the responder. Record the address family of each as well. An IPv4 range and an IPv6 range are different selector types, and neither can be folded into the other's payload.

Add any protocol or port restriction that policy carries. A rule permitting only TCP 445 to a file server describes a narrower set than the subnet it sits in. Leave that out of your notes and the negotiation result will look inconsistent for reasons you cannot see.

Reverse the labels before comparing them

Local and remote are relative labels. The client's local prefix is the gateway's remote range, and the gateway's local range is the client's remote. Screenshots from the two ends therefore never line up, and comparing them literally is the standard way to lose an afternoon.

A responder may narrow an offer to an acceptable subset instead of rejecting it. That outcome is worse than a clean failure, because it half works. Ask for 10.0.0.0/16 when policy permits 10.0.5.0/24 and you can end up with a child SA covering only that /24. One host answers, everything else falls outside, and nothing in the client says so. Read the accepted selectors rather than the requested ones before you conclude that negotiation succeeded.

Road-warrior profiles that request a default route land here constantly. A gateway built for split access narrows a full-range offer to its own subnets, and the client must accept the narrowed result or fail loudly.

Read the rejection from one attempt

Collect both logs from the same connection attempt. A saved profile shows what you configured, not what was proposed, and on strongSwan swanctl --log prints the received notify together with the selectors it carried.

Then inspect what actually got installed. swanctl --list-sas shows the child SA's selectors, and ip xfrm policy shows the same ranges as kernel policy entries. A child SA in that listing with selectors you did not intend is a narrowing event; no child SA plus TS_UNACCEPTABLE in the log is a refusal.

Separate the near neighbours while you are in there. INVALID_SELECTORS complains about a selector inside an established child SA, while INTERNAL_ADDRESS_FAILURE means the responder could not allocate a virtual address, which is a pool problem rather than a coverage problem.

Check what silently shrinks the set

Three things shrink a selector set without saying anything. Responder policy is the first, through subnet lists, group rules or per-user authorization that reduce the offer to a subset. Address family is the second: a dual-stack client often proposes IPv6 alongside IPv4 and gets a rejection for ranges the gateway never configured.

Protocol and port restrictions are the third. Where policy allows only TCP 445, a child SA can come up while ICMP and UDP remain outside it, and the user reports a broken tunnel when one protocol was all that was ever permitted.

Widening addresses alone therefore cannot fix a port-restricted policy, which is the case most likely to survive three rounds of troubleshooting unchanged.

Prove coverage with traffic that fits

After the child SA installs, send one request that certainly falls inside the accepted ranges. Watch the counters instead of the status icon: ip -s xfrm state and the counters behind ip xfrm policy increment when a packet is matched and protected. A byte count that stays at zero after real traffic means the kernel never selected that policy.

That zero is a routing or policy-order problem, not a crypto problem. It also looks identical to a selector rejection from the user's seat, which is why the counters are worth collecting before you reopen the profile. Counters that climb in one direction only point at the return path instead.

Finish by writing the accepted pair into the ticket, next to the range that was originally requested. Keep the selection as narrow as the requirement, because clearing the error by replacing a private range with every address grants far more access than the account was approved for.