Anyconnect VPN Extended ACLs No Longer Restricting Users

[City of Kalamazoo]

I typically setup remote users to use the Anyconnect client (ver.
3.1.02026) to connect to our ASA5510, restricting them to DNS and RDP protocols only. 
Today I went to setup a new user and after testing their setup I noticed that no matter
what I place in their ACE, they are able to get to all devices on our network.  I even
place a Deny All ACE in their ACL and then connected with their profile and they were
still able to ping, RDP, etc. into any device on our network.  I took a look at some
existing profiles that were setup several months ago and tested and confirmed to work
correctly back then and they were not longer restricting users any longer.
It seems as if my ACLs are being ignored.
One other piece of information to note is about 2 months ago I received a message that the
ASA couldn't save my settings via ASDM.  I closed ASDM and attempted to log back in and
received an error (I can't remember the exact error) that a file had been corrupt during
writing to the ASA.  After a quick search on the web I found a solution to fix this issue
by a check disk command on the ASA via CLI.  I notice the next day that Anyconnect had
been disabled.  So I re-enabled it and made sure VPN users could connect, which they
could.  At that time I did not test the ACLs to see if I had a problem at that point.  I'm
not sure if something deep within my ASA also got changed during this corruption and if
so, I'm not sure where to even start.

[Jouni Forss]

Hi,

What ACLs are we exactly talking about here?

VPN Filter ACL? Split Tunnel ACL? Interface ACL?

Can you share any configurations?

Even though your post seems to hint that you are using some ACLs attached to group-policy perhaps I will still mention one possibility just incase.

If you were previously controlling the VPN user traffic with the "outside" interface ACL and its not working anymore then you might want to check if you have the setting "sysopt connection permit-vpn" on. The default setting is that its on and therefore doesnt show in the CLI configuration.

If you have the "no sysopt connection permit-vpn" then every connection attempt coming through a VPN connection will be matched to the interface ACL rules. Usually the VPNs are terminated to the "outside" interface of the ASA and would therefore be controlled in that interfaces ACL.

- Jouni

[City of Kalamazoo]

These are extended ACLs, each being setup specifically for a specific end user's Group Policy.  So let's say an end user Sam needs to connect to a computer named PC05(192.168.100.10), I would setup a brand new ACL and two ACEs for this new VPN Group Policy.  Once ACE would allow port 53 (Domain/DNS) traffic to our two domain controllers.  The second ACE would allow port 3389 (MSFT RDP) traffic to PC05. 

Upon testing one of these connections, I usually can try and ping PC05 by name and it would resolve to it's IP (192.168.100.10), but I wouldn't get replies.  But I could obviously RDP to this PC just fine.  If I tried pinging one of the two domain controllers by name, I again would get DNS resolution, but no replies.  If I tried to RDP to one of the two domain controllers, it would fail.

That's how it used to work, as expected with the above two ACEs in the ACL. 

However, when I test any of my existing user's ACLs or even if create a brand new one, I can't restrict any of this traffic.  The end user can RDP to our domain controlelrs, I get replies back when pinging, etc.  If I go as far to create a new ACL with an ACE entry that denies all IP (all ports) traffic, I then can communicate with anything on our network.  No restrictions at all.

I did a search in a recently saved config and I don't see the command "sysopt" in my config either.  (I rarely use the CLI. 90% of my interaction with the ASA is through ASDM.)  The Anyconnect VPN clients are connecting to our outside interface, but are given IPs from a DHCP scope on the ASA....not sure if that helps or not.

[City of Kalamazoo]

I guess I didn't clarify what type of ACLs I'm referring to either.  We're talking about Split Tunnel ACLs.

For example, the below rule is passing traffic to everything BUT what is listed in the rule.

access-list AvailSupport_ExAcl extended permit ip object-group Avail_Devices 192.168.105.0 255.255.255.0

object-group network Avail_Devices

network-object 10.30.75.0 255.255.255.0

network-object host 10.30.112.200

network-object host 10.30.112.201

network-object host 10.30.112.202

network-object host 10.30.112.203

network-object host 10.30.112.204

network-object host 10.30.112.205

network-object host 10.30.112.206

network-object host 10.30.112.207

network-object host 10.30.112.208

network-object host 10.30.112.209

network-object host 10.30.114.50

network-object host 10.30.114.51

network-object host 10.30.114.52

network-object host 10.30.114.53

network-object host 10.100.114.51

network-object host 10.30.114.55

network-object host 192.168.9.60

[Jouni Forss]

Hi,

If you use the above ACL as a Split Tunnel ACL it simply forwards all traffic from the VPN Pool 192.168.105.0/24 to the IP addresses/networks defined in the "object-group". It doesnt really mention any services in it and therefore the VPN connection will forward all traffic to the VPN connection wether it was DNS, ICMP or RDP.

Usually specific access rules for VPN users arent handled in the Split Tunnel ACLs. Split Tunnel ACLs should first tell to which networks/hosts the VPN Client needs access.

A separate VPN Filter ACL or the interface ACL should then control what specific ports etc are allowed through.

If at the moment you cant see the "sysopt" configuration in the CLI for the VPN connections then this would mean that all incoming traffic from VPN connections bypass your "outside" interface ACL checks.

When you can see a configuration line "sysopt connection permit-vpn" in the CLI format then this would mean that "outside" interface ACL is being used to control VPN user traffic.

I guess this is a bit of a guessing game wihtout seing some configurations.

- Jouni