Why an ASA remote user reaches the subnet but not the app
Routes prove the tunnel works, not that the user may open the app. Read the filter the session received, then test a permitted and a denied connection.
Your user connects, gets an address, pings a server in the application subnet, and still cannot open the service on it. That combination is normal on an ASA, because a successful tunnel and a usable permission are decided by different settings. The split-tunnel list chose which destinations entered the tunnel; a VPN filter and the destination's own access rules decide what the decrypted request may reach. Work through the three decisions in order rather than widening the route list until something changes.
Three decisions that are easy to confuse
Admission answers whether the user may establish the tunnel at all: credentials, certificate, and any second factor. Route selection answers which destinations the client sends into that tunnel. Authorization answers whether the decrypted request may reach the service. Only the third one produces the error the user is reporting.
A quick way to tell them apart is to ask what a change would break. Removing a route from the split list stops traffic to that subnet without granting anything; adding an ACE to the VPN filter grants a destination without changing what the client tunnels.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Read the filter the session actually received
Start from the live session instead of the configuration you think applies. show vpn-sessiondb detail anyconnect prints the assigned group policy and the filter name attached to that session. If the field is empty, no filter is enforcing anything and the block is coming from somewhere else.
Then read the policy that owns the value, including defaults, because a filter can be inherited rather than written where you are looking:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Compare the filter name on the session with the ACL you just edited. A similarly named ACL that the user never received cannot change that session's resource policy, and this is the most common reason a correct-looking change has no effect.
Precedence explains the rest. For the filter setting, a DAP record outranks username attributes, and username attributes outrank the group policy. When a session shows a filter you did not expect, look for a DAP policy matching that user before you touch the group.
The split list and the filter are separate fields
On ASA 9.x the group policy holds split-tunnel-network-list and vpn-filter as different settings, and the 9.22 group-policy guide documents them separately for that reason. The network list is a routing hint to the client; the filter is an access control list applied to decrypted traffic.
That distinction matters when a user needs one HTTPS service on a subnet. Put the subnet in the split list so the packets enter the tunnel, then permit only that service in the filter. Expanding the route list authorizes nothing, and shrinking it is not an enforcement mechanism.
Check whether an interface ACL is even in the path
Decrypted remote-access traffic does not always traverse the outside interface ACL the way people assume. Where sysopt connection permit-vpn is enabled, the ASA applies its documented VPN bypass for that traffic, while applicable VPN filters still apply afterwards. Check the setting with show run all sysopt rather than reasoning from the topology diagram.
Either way, the destination host's own firewall and the application's authorization remain in the path. An ASA rule that permits TCP 443 does not make the application accept the user.
Accept the change with a denied connection too
A permitted test alone proves very little, because a working tunnel produces the same first packet whether or not a filter exists. Open the intended service from the client, then attempt a destination that should stay closed and confirm it fails for the right reason.
Record four facts when you close the ticket: the admitted identity, the policy and filter the session actually received, the destinations in the split list, and the resource the user was allowed to reach. Those four explain where the traffic is controlled without turning a routing list into a firewall.
If the service still refuses after the filter permits it, move to the host: listen address, host firewall, and the application's own user mapping. The tunnel did its job at that point, and further ASA changes only add risk.