Check Point VSX VPN: Link Selection or a Peer Mismatch?

Two different changes produce the same symptom when a Check Point site-to-site tunnel stops coming up: the peer sees a different outer address, or it rejects the IKE identity it now receives. On a capture taken from one side they look identical. Deciding which one you have takes three checks, and none of them is the Link Selection pane.

Get the order wrong and you tune source selection to fix an identity mismatch. That is how the same tunnel gets fixed twice and breaks again after the next route change.

Three conditions that separate the two cases

Condition one: does the peer's configured endpoint match the address that actually arrives? If packets reach the remote gateway from an address it does not associate with your peer object, negotiation fails before any identity is exchanged. Condition two: does the IKE identity in the proposal match the peer's expected value? That is authentication, not transport. Condition three: is the option you want to change supported for this virtual system on this release? A visible setting answers none of these.

If condition one fails, you have a routing or translation problem. If condition two fails, you have a peer-contract problem. If condition three is unknown, stop configuring.

Build the outer-peer record first

Write down the virtual system, the software release and the installed update level before touching anything. Then record the external interfaces, the route toward the remote peer, the expected pre-NAT and post-NAT source addresses, and the remote peer's configured endpoint.

Keep the inner protected prefixes in a separate part of that record. Changing an outer source and changing a protected LAN address are different operations that happen to live in the same policy.

Add direction to every capture you keep. A locally initiated negotiation and a response to the remote peer can select differently, so an unlabelled capture is weak evidence. Label the file with the virtual system and the initiator.

Read what Link Selection actually separates

Check Point's R81.20 Link Selection guide separates three things people merge into one: how the remote peer resolves a gateway address, which route carries outgoing traffic, and which source IP is used. Each answers a different question. None of them changes what identity the peer authenticates.

That separation explains why a route change can alter the visible outer address without touching the IKE identity, and why an identity change can break a tunnel whose routing is perfect.

RFC 7296 draws the same line for IKE itself: the identification payload is not the transport address. Vendors implement that split, they do not redefine it.

Decide with evidence, not with the settings pane

If the peer reports an unknown or mismatched identity, fix the peer object or the identity configuration, not the source selection. If the peer reports nothing and your capture shows packets leaving from an unexpected address, fix routing or translation first. If both look right and the tunnel still fails, capture on the remote side and compare what it received. Only when address and identity agree and the path is still wrong does a Link Selection option become the candidate.

Before configuring that option on VSX, get the matching release's supported-feature guidance or an explicit vendor statement for the virtual-system context. An older report that a feature was unavailable is history, not a current prohibition, and a settings pane is not a support statement.

Reconcile both ends and keep the record

Once you have a supported design, review external reachability, the peer endpoint configuration and the identity agreement together, as one contract. Then plan acceptance for three cases: initial connection, remote-initiated connection, and the failure you expect when the path breaks.

Save the observed outer addresses next to the active virtual-system context. The next route change then compares against a documented contract instead of somebody's memory of the default.