Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

SSL VPN client ACL not affecting access

I have an couple ASA5510's that are used for VPN access to our network.  One also supports a tunnel to a 5505 at a branch office.  We are using a DAP to manage VPN user access from ActiveDirectory.  I would also like to allow Contractor/Vendors access to specific hosts that they may support from remote offices. So I have two profiles, one for the general employees that authenticated via LDAP and another for third-party-connections that authenticates locally.  So employees have AD accounts, but contractor/vendors do not.  I specify an address to assign to the individual contractor/vendor usernames.  I then wish to use an ACL to restrict those usernames to specific host access based on thier IP address.  Seems simple enough, but it seems that my ACL is having no affect.  The contractor/vendor usernames can access everything.  Following is clips from my config that show my profile, GP, TG, ACL, and username config.  Can anyone offer suggestions as to why the ACL does not restrict the user like it's supposed to???

username contractor1 password aSQ2x9iBrbxo4hCT encrypted

username contractor1 attributes
vpn-group-policy Z_Contractor_Access
vpn-filter value 150
vpn-framed-ip-address 10.195.28.48 255.255.255.0
group-lock value Z_Contractor_Access
service-type remote-access

group-policy Z_Contractor_Access internal
group-policy Z_Contractor_Access attributes
vpn-simultaneous-logins 3
vpn-filter value 150
vpn-tunnel-protocol svc webvpn
group-lock value Z_Contractor_Access
nac-settings none
webvpn
  svc modules none
  svc routing-filtering-ignore disable

tunnel-group Z_Contractor_Access type remote-access
tunnel-group Z_Contractor_Access general-attributes
authentication-server-group (inside) LOCAL
authorization-server-group LOCAL
default-group-policy Z_Contractor_Access

tunnel-group Z_Contractor_Access webvpn-attributes
group-alias Z_Third-Party enable

access-list 150 extended permit ip host 10.195.28.48 host 10.195.24.6
access-list 150 extended permit ip host 10.195.28.48 host 10.195.24.7
access-list 150 extended deny ip host 10.195.28.48 any
access-list 150 extended permit ip any any

11 REPLIES
Cisco Employee

Re: SSL VPN client ACL not affecting access

When "contractor1" user logs in, can you please issue the following on the ASA:

show vpn-sessiondb detail svc filter name contractor1

Just want to make sure that the user is actually logged in under group-policy "Z_Contractor_Access" and assigned ip address of 10.195.28.48.

As far as the vpn filter ACL is concern, it looks correct to me. The user should only have access to 10.195.24.6 and 10.195.24.7.

You might even want to remove "access-list 150 extended permit ip any any" as it shouldn't really have a need to use that particular line.

New Member

Re: SSL VPN client ACL not affecting access

Session Type: SVC Detailed

Username     : contractor1            Index        : 2317
Assigned IP  : 10.195.28.48           Public IP    : 192.168.1.2
Protocol     : Clientless SSL-Tunnel DTLS-Tunnel
License      : SSL VPN
Encryption   : RC4 AES128             Hashing      : SHA1
Bytes Tx     : 18884                  Bytes Rx     : 15127
Pkts Tx      : 143                    Pkts Rx      : 136
Pkts Tx Drop : 0                      Pkts Rx Drop : 0
Group Policy : Z_Contractor_Access    Tunnel Group : Z_Contractor_Access
Login Time   : 09:47:37 EDT Mon Aug 2 2010
Duration     : 2h:04m:34s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none

Clientless Tunnels: 1
SSL-Tunnel Tunnels: 1
DTLS-Tunnel Tunnels: 1

Clientless:
  Tunnel ID    : 2317.1
  Public IP    : 192.168.1.2
  Encryption   : RC4                    Hashing      : SHA1
  Encapsulation: SSLv3                  TCP Dst Port : 443
  Auth Mode    : userPassword
  Idle Time Out: 30 Minutes             Idle TO Left : 0 Minutes
  Client Type  : Web Browser
  Client Ver   : AnyConnect Windows 2.5.0217
  Bytes Tx     : 10915                  Bytes Rx     : 3227

SSL-Tunnel:
  Tunnel ID    : 2317.2
  Assigned IP  : 10.195.28.48           Public IP    : 192.168.1.2
  Encryption   : RC4                    Hashing      : SHA1
  Encapsulation: TLSv1.0                TCP Src Port : 1065
  TCP Dst Port : 443                    Auth Mode    : userPassword
  Idle Time Out: 30 Minutes             Idle TO Left : 0 Minutes
  Client Type  : SSL VPN Client
  Client Ver   : Cisco AnyConnect VPN Agent for Windows 2.5.0217
  Bytes Tx     : 582                    Bytes Rx     : 0
  Pkts Tx      : 1                      Pkts Rx      : 0
  Pkts Tx Drop : 0                      Pkts Rx Drop : 0

  Filter Name  : DAP-ip-user-60377B0B

DTLS-Tunnel:
  Tunnel ID    : 2317.3
  Assigned IP  : 10.195.28.48           Public IP    : 192.168.1.2
  Encryption   : AES128                 Hashing      : SHA1
  Encapsulation: DTLSv1.0               UDP Src Port : 1073
  UDP Dst Port : 443                    Auth Mode    : userPassword
  Idle Time Out: 30 Minutes             Idle TO Left : 27 Minutes
  Client Type  : DTLS VPN Client
  Client Ver   : AnyConnect Windows 2.5.0217
  Bytes Tx     : 7387                   Bytes Rx     : 11900
  Pkts Tx      : 129                    Pkts Rx      : 130
  Pkts Tx Drop : 0                      Pkts Rx Drop : 0
  Filter Name  : DAP-ip-user-60377B0B

NAC:
  Reval Int (T): 0 Seconds              Reval Left(T): 0 Seconds
  SQ Int (T)   : 0 Seconds              EoU Age(T)   : 7486 Seconds
  Hold Left (T): 0 Seconds              Posture Token:
  Redirect URL :

Cisco Employee

Re: SSL VPN client ACL not affecting access

The output seems to be correct.

What test has been performed that show that they can access everything else apart from 10.195.24.6 and 10.195.24.7?

I also see that there is no split tunneling policy configured, hence internet browsing should not work at this stage i assume?

New Member

Re: SSL VPN client ACL not affecting access

I can log in with the contractor1 account.  I get the IP address 10.195.28.48.  I can ping and telnet to devices on other subnets, like 10.195.23.1.  Based on the ACL configured, I shouldn't be able to do this.

No split tunneling is configured.  The only purpose of this connection is for an outside contractor to access a device on our network that they support.

Cisco Employee

Re: SSL VPN client ACL not affecting access

Not sure if you configured the vpn filter first prior to connecting via Anyconnect client, or vpn filter was configured while you are connected via the Anyconnect.

If it's the later, please kindly make sure that you log out and log back in again to the Anyconnect before trying to test the access again.

Please also make the following changes prior to the test:

- Just configure the following 2 lines for ACL 150:

     access-list 150 extended permit ip host 10.195.28.48 host 10.195.24.6
     access-list 150 extended permit ip host 10.195.28.48 host 10.195.24.7

Please kindly remove the other 2 lines which are not required.

New Member

Re: SSL VPN client ACL not affecting access

I was logging in/testing from the client after the ACL was applied.

I removed all but the two specific permit statements in the ACL.  Disconnected/reconnected and tested.  Still the same results though.  It's like the ACL is being ignored....

New Member

Re: SSL VPN client ACL not affecting access

Just to be clear:  you removed the "access-list 150 extended permit ip any any" statement right?

I have a restricted ACL similar to what you are doing and mine does not have a "permit ip any any"

New Member

Re: SSL VPN client ACL not affecting access

The permit any any statement was after the deny 10.195.28.48 any, so it really shouldn't have any affect anyway ( except for traffic other that 10.195.28.48 that may have the same acl applied ).  I removed it and the result is still the same.

New Member

Re: SSL VPN client ACL not affecting access

Looking through my config again, I see that i'm actually assigning the ACL via DAP rather than as a group-policy VPN filter:


access-list CONTRACTOR extended permit tcp any host 10.10.8.49 eq www
access-list CONTRACTOR extended permit tcp any host 10.10.8.49 eq https

dynamic-access-policy-record DfltAccessPolicy
dynamic-access-policy-record RESTRICTED_CONTRACTOR
description "Restricted role for Contractors"
network-acl CONTRACTOR


New Member

Re: SSL VPN client ACL not affecting access

Ok.  I changed my config to the following:

access-list 150 extended permit ip host 10.195.28.48 host 10.195.24.6
access-list 150 extended permit ip host 10.195.28.48 host 10.195.24.7

dynamic-access-policy-record Z_Contractor_Access
description "Z_Contractor_Access"
network-acl 150
priority 6

group-policy Z_Contractor_Access internal

username contractor1 password aSQ2x9iBrbUo4xCT encrypted

username contractor1 attributes
vpn-framed-ip-address 10.195.28.48 255.255.255.0
service-type remote-access

tunnel-group Z_Contractor_Access type remote-access
tunnel-group Z_Contractor_Access general-attributes
default-group-policy Z_Contractor_Access
tunnel-group Z_Contractor_Access webvpn-attributes
group-alias Z_Contractor_Access enable

With this config the ACL should be applied by the DAP.  However, the result remains the same.  The ACL still appears to have no affect on traffic.

New Member

Re: SSL VPN client ACL not affecting access

I found the answer for anyone who might have been following this or is having similar issue.

Any DAPs that have no selection criteria will be applied to all connection profiles.  There was a DAP created on my ASA that was used for another connection profile that was not specified in the selection criteria for the DAP.  It was therefore, applied to my contractor profile by default.  I would have expected that the ACL specified in the local username attributes for the contractor id would take precedence.  However it doesn't.  It appears that any ACLs specified by a DAP takes precedence over any ACLs that you would specifiy in username attirbutes.  I added selection criteria to the DAPs to specify the connection profiles that they are for and everything worked fine after that.

555
Views
0
Helpful
11
Replies
CreatePlease to create content