Because you don't currently have any group-url or group-alias definitions on any tunnel-groups, your users will use DefaultWEBVPNGroup's settings, which use local authentication (rather than something like RADIUS, TACACS, or LDAP) and will use the default group-policy DfltGrpPolicy.
Because of this, you have 3 options.
Option 1: You can edit DfltGrpPolicy so that it uses the VPN filter you previously created (alternatively you could also set it to use different authentication methods). If you do this, it will also affect your site-to-site tunnel and anything else using DfltGrpPolicy (because you don't have another policy defined for them to use instead).
To do so, you can type:
group-policy DfltGrpPolicy attributes
vpn-filter value CLIENT-VPN-LIST
Note: I strongly recommend against Option 1.
Option 2: You can edit DefaultWEBVPNGroup so that it uses a different group-policy than the tunnel-groups for DefaultRAGroup, DefaultL2LGroup, and 10.1.1.2, so they won't be impacted.
To do so, you can type:
tunnel-group DefaultWEBVPNGroup general-attributes
default-group-policy CLIENT-VPN-POLICY
Note: Option 2 is okay to use if you want there to be a catch-all for users that don't use a group-alias or group-url to direct them somewhere more specific, but I usually don't recommend modifying it for most setups.
Option 3: You can use the tunnel-group you already previously created, called CLIENT-VPN-GROUP, and add a group-alias to it so that users can be mapped to the appropriate policy.
To do so, you can type:
tunnel-group CLIENT-VPN-GROUP webvpn-attributes
group-alias vpn enable
If you choose Option 3, users would then be able to access your VPN by going to a URL such as https://<public IP address>/vpn
. As long as the /vpn
is appended to the end, it will map the users to the tunnel-group that is configured with that alias/group and subsequently map them to the appropriate policy.
Edit:
It was my mistake for forgetting that clientless VPN doesn't use vpn-filters like client VPN does, and you have to use a WebType ACL to filter traffic based on either URL or TCP-based destinations.
You can still keep the existing VPN-filter in place in case you want the same filtering on a client as well, but it can't be the same ACL since they're different types, meaning you will have 2 ACLs to maintain if you want to make modifications later. Another caveat is that WebType ACLs can't use objects or object-groups - they need to be literal.
To create a WebType ACL, you can add the following to your policy:
access-list CLIENT-VPN-LIST-WebType webtype permit tcp host 192.168.50.2 eq 3389
access-list CLIENT-VPN-LIST-WebType webtype deny tcp any
access-list CLIENT-VPN-LIST-WebType webtype deny url any
And then to add it to your existing group-policy, you can type:
group-policy CLIENT-VPN-POLICY attributes
webvpn
filter value CLIENT-VPN-LIST-WebType
You will need to log out of the VPN portal and back in for it to take effect.
show run all tunnel-group
and show me the output so I can see what you do have?show webvpn group-url
andshow webvpn group-alias
? Also, your users will need to go to something to access the VPN login page, which is usually a URL with an FQDN with or without a group/alias (such ashttps://vpn.company.com
orhttps://vpn.company.com/group
), but could just be a URL with an IP address and group/alias (such ashttps://100.200.100.200/group
). Please clarify what it is that your users go (will go) to, to access the VPN.