One /23 instead of two /24s: what changes in the negotiation

Two adjacent /24s collapse neatly into one /23, and that tidy arithmetic convinces people the change is cosmetic. It is arithmetic about addresses, and the tunnel cares about selectors, which are a negotiation offer rather than a description of a network. The shorter line can leave the same traffic protected, protect more than intended, or fail to cover half of it depending on what the two peers are willing to accept. Reading the installed result is the only way to know which of those three happened.

Three facts people merge into one

The address set says which hosts are meant to be protected. The grouping says how those addresses are offered, one selector or several, in one association or more. The negotiated result says what the two peers actually installed, and it can be narrower than either of the first two.

Write them separately in the change record. A single line of configuration often hides three different answers. A reviewer who cannot separate them cannot approve the change either.

What the responder is allowed to do with your aggregate

An IKEv2 responder may narrow an offered selector pair to a subset it is willing to accept, and it may refuse the offer outright if nothing acceptable exists. It can also indicate that additional traffic needs another association rather than fitting into this one.

A responder that accepts nothing returns an error instead, which at least says the offer was rejected rather than quietly narrowed.

That means a successful exchange proves the peers agreed on something, not that they agreed on everything you listed. The initial success message is a starting point for reading the result, never a conclusion. The accepted subset can be smaller than a single /24, which makes the installed set look nothing like the offer.

Where a summary quietly erases a boundary

Two /24s can hold different service rules: one may permit only a management protocol, the other a general application. A selector that covers both addresses at the IP layer does not preserve those rules, and the summary moves the boundary into whatever filtering exists behind the tunnel. List the service rules per subnet before aggregating, or that comparison never happens.

Protocol and port values are part of a selector, not an optional extra. If the original policy restricted them, the aggregate has to carry the same restriction or the change is a permission change wearing a routing costume. If the restriction was the point of the original policy, keep it explicit after the summary and say so in the record.

Reading the result per prefix

After the change, look at what was installed rather than at what was configured. Then generate a flow from each prefix in each direction, and check the counters that belong to the association handling it. Two prefixes that produce traffic on one association are fine; two prefixes where one produces nothing are the finding.

Do this with the same application the users run. A probe that originates on the gateway tests a different path than a client behind it, and the difference is exactly where selector bugs hide. A flat counter on a prefix that should be busy is stronger evidence than any log line, because it measures absence.

Making the change reversible

Keep the original policy in the configuration until the new one has been exercised from every prefix combination, and note which association each flow landed in. If a peer replaces associations when the offer changes, the rollback has to restore the old offer and not merely the old addresses.

Coordinate with the owner of the other endpoint before the window opens. A summary that one side considers obvious may be an unacceptable grouping on the other, and finding that out during the change is expensive. Agree on the offered grouping in writing, then compare it with what the exchange installs. Keep that agreement in the change ticket, not in a chat thread that disappears next week.