Does a VPN Subnet Get the ASA Interface Security Level?

A decrypted VPN subnet never inherits an interface security level. Check sysopt connection permit-vpn, the group filter and management access separately.

Someone asks whether the branch VPN subnet is "security level 0 or 100" on the ASA, and the question already contains the mistake. Security level is a property of a local interface, assigned 0 to 100 in the interface configuration. A remote subnet arriving through a tunnel does not acquire one, no matter how the crypto map is written. That is why the question has no numeric answer.

The practical follow-up is better: which policy admits the branch to the server, and which one keeps it away from the firewall itself. Those are two answers, and the procedure below separates them.

Security levels belong to interfaces

Run show running-config interface and you will see security-level under each physical or VLAN interface, not under the tunnel group or the crypto map. The default higher-to-lower permit is evaluated between those interfaces, which is why the number changes inspection and implicit-ACL behaviour on the path it belongs to.

For a decrypted VPN flow, the ingress is still the outside interface where the tunnel terminates, and the egress is the inside interface toward the server. Write both down before you touch anything. That single step kills most of the confusion, because it turns an abstract trust question into an interface pair.

The ACL bypass has a named boundary

sysopt connection permit-vpn is the setting people half-remember when they say VPN traffic ignores ACLs. It does skip the interface ACL for traffic that qualifies as VPN traffic, and the 9.x parameter guide scopes it by interface and direction rather than declaring a global exception.

Check what is configured before reasoning from memory:

  • show running-config all sysopt to see the effective value, not just the non-default lines.
  • show running-config access-group to see which ACL is applied to which interface and direction.
  • show vpn-sessiondb detail l2l to confirm which tunnel group and filter the session actually uses.

Turning that setting off to tighten VPN access is a change with blast radius. It re-subjects every qualifying VPN flow to the outside ACL, which usually breaks working tunnels in ways unrelated to the branch you were asked about.

Read the filter attached to the session

The real per-tunnel control is the VPN filter: an ACL referenced by group policy or by username, applied after decryption and before encryption. A user-level filter overrides the group-level value, so two people on the same tunnel group can have different effective access.

Confirm the precedence instead of assuming it. show running-config group-policy <name> shows the group value, and show running-config username <name> shows whether a per-user value exists. If both exist, the user value wins. Then compare that ACL's entries against the flow you care about, in the direction the filter evaluates.

A filter that permits the application server says nothing about management. Those are separate rules on a separate path.

Verify one permit and one deny

Packet-tracer is the fastest way to see the decision without waiting for a user to report it. Give it the decrypted-side flow and let it name the ACL, NAT and inspection stages it passes through.

  1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
  2. Read the result line: it names the ACL that permitted or dropped the packet.
  3. Repeat with the administrative destination on the inside interface and confirm a deny.
  4. Repeat once more after any change, so the before and after states are both recorded.

Then verify with real traffic: one successful application request from the branch and one failed SSH attempt to the ASA. Packet-tracer models the path; a live flow proves the model matched.

Roll back the change that made it work

If the fix was disabling the ACL bypass or widening a filter, keep the previous configuration. A show run capture of the affected objects, saved before the change, is enough to restore them; ASA configuration is line-oriented, so reverting means re-entering the old lines, not restoring a file.

Record the interface pair, the effective filter, the ACL name from packet-tracer, and the exact commands you changed. That record turns the next review into a five-minute check instead of another debate about trust levels.

Artaigilean co-cheangailte