Which ASA Rule Sees the Traffic After the VPN Decrypts It

The assumption to drop first is that the crypto ACL is an access policy. It is not. On a Cisco ASA, that list answers one narrow question about which packets deserve protection, and the answer has nothing to say about whether the decrypted packet may reach the server behind the firewall. Access is decided later, by an interface policy, by a group-policy filter, or by both, depending on how the tunnel was built.

The crypto ACL answers a different question

A crypto ACL is a match list. It tells the tunnel what to encrypt between two peers; a packet that does not match it simply is not protected. Widening it changes the scope of protection and nothing else.

That is why adding a subnet there can make a tunnel come up while the actual application still fails. The tunnel is up because a match now exists. The application still fails because nothing in that list permits anything. Two different questions, answered by two different lists.

What the bypass setting really skips

sysopt connection permit-vpn lets protected traffic skip the interface ACL check that would otherwise apply on the inbound side. It is a convenience for VPN deployments, and it is global. It does not touch the group policy, and it does not touch a per-user authorization filter.

Read the live value rather than the assumption: show running-config all sysopt prints the setting even when it was never explicitly configured, which is where a lot of confusion starts.

Because the setting is global, testing it as a quick experiment on one failing subnet is a bad trade. Every other tunnel on that firewall shares the result. Save it for a deliberate change with a rollback plan.

Read the filter in the decrypted direction

A LAN-to-LAN vpn-filter is written from the tunnel's point of view, not the interface's. The remote network goes in the source position and the local network in the destination position, because that is what the packet looks like after decryption. The same filter is then evaluated again in the opposite direction before encryption, with the address roles reversed.

Port conditions deserve more care than a copied interface ACL for exactly that reason. A rule permitting one destination port can have an unintended effect in the reverse direction, where a new connection uses that port as its source. Write down which side may initiate, the actual service, and the counterpart that must stay closed before you build the list.

Confirm which filter is actually attached: show running-config group-policy and show vpn-sessiondb detail l2l together tell you what the session inherited. Editing an ACL that no policy references changes nothing.

Do not reuse one ACL object for two jobs

An interface access-group and a vpn-filter look like the same kind of object and are evaluated at different points with different address orientations. Assigning one list to both invites a change that fixes the tunnel and quietly loosens the physical interface.

Keep them separate, name them for their job, and let the difference in direction be visible in the names.

Verify with new connections, in both directions

After a planned change, open one fresh connection that should be permitted and one fresh connection that should be denied, then keep the addresses, the direction and the policy match with the result. An established session proves nothing about new-connection filtering, because it was already admitted under the old rules.

Account for inspection as well. The vendor documentation notes that a VPN filter checks the initial connection rather than every secondary connection an inspection engine opens, so a control channel and its related media flow can receive different treatment. If the application is protocol-aware, test the actual flow rather than a single port probe.

A tunnel that becomes usable after a broad bypass tells you the restriction was removed, not that it was satisfied. The outcome worth keeping is a named enforcement point you can point at during the next review.