A Broad IPsec Selector Is Not Permission to Every Service

Two peers agree to protect a whole subnet, and someone reads that agreement as permission to reach every service inside it. That is the myth: the selector says which traffic the tunnel is willing to carry, and it says nothing about which services the organisation allows. A pair of devices can legitimately negotiate a broad address range while the access policy inside it permits two ports, and both statements remain true at the same time.

Protected coverage is not authorisation

A traffic selector is part of the tunnel agreement. It narrows or confirms what the peers will encrypt between them, and a broad selector is often the simplest thing to operate when the two sides have many flows to carry. The service filter is a different control at a different point in the path, and it decides what may actually be used once the packet has been decrypted. Removing the filter to make one test pass converts a policy decision into an accident.

Keep the two records separately in the design document, because a reader who sees only the selector will infer authorisation that was never granted. Two lines in a change record prevent that, and they take less time than the argument that follows.

Describe one flow from both ends

Write down the initiator, the responder, the source and destination as presented, the protocol and both ports. Then reverse every one of those labels for the other endpoint, because a client's ephemeral source port becomes the destination port of a reply and the remote network becomes the local one. A configuration copied from one side to the other without that reversal is how filters end up permitting exactly the wrong direction. Write the table once and build both filters from it.

Agree the selection model before copying anything, since a policy-based design and a route-based design express the same intent through different objects. Write the model name next to the flow, or the next engineer will spend an afternoon matching objects that were never comparable.

Find the filter that actually applies

On an ASA, the VPN filter is an ACL attached to a group policy and applied to post-decrypted and pre-encrypted traffic. Cisco's group-policy documentation also describes inheritance, including a user-level value that supersedes the group-policy value. So the ACL you edited may not be the ACL that governs the session in front of you. The same is true of the user object, which can override the group without leaving much visible evidence behind.

Inspect the effective session rather than the object you remember changing, and note which policy object supplies it. That single step resolves a surprising number of "the filter is right but it is not working" reports.

Direction, ports and the reverse case

The documented convention places the remote network, or the assigned remote-client addresses, in the source position and the local network in the destination position, with replies expressed by swapping the address positions. Port rules sit on top of that convention and deserve more care than the addresses do.

The documented model can let a destination-port rule affect reverse initiation that uses that same source port, which means the filter is not simply a one-way request rule with harmless replies attached. Reason through both initiation directions explicitly, and include the case you intend to deny.

The same documentation limits the filter to initial connections, so it is not universal enforcement of every secondary channel an inspected application opens. Where the complete policy needs that coverage, it belongs at a separate boundary rather than in an ACL being stretched past its purpose.

Test three cases before calling it done

Accept the intended flow, refuse a service that the policy prohibits, and exercise the reverse-direction case you reasoned about. Run them under an approved plan with the same identities and selectors you will deploy. A test that only shows the permitted service working demonstrates the tunnel, not the policy.

Keep the negotiated coverage and the access decision as two records, because explaining what a VPN permits requires both of them.