Firepower RA VPN with dACL not working

[erik.hammervold]

I'm testing Downloadable Access-lists on a RA-VPN setup But can't seem to get the dACL to be attached to the clients connections. I cannot seem to find a config-guide that explains to me a setup on the Firepower, or if the Firepower just is supposed to eat the av-pair response from the ISE and just attach the dACL to the user-session.

On the ISE I have defined the dACL and checked syntax, defined the dacl in the auth-profile, added the profile to the rule name as a result. In the ISE log I can see the user hits the right rules and that the dacl is served.

15016 Selected Authorization Profile - <xxx-vpn-profile-xxx>
11022 Added the dACL specified in the Authorization Profile.

This is the av-pair response sent to the Firepower from the ISE when testing with the default permit dACL

cisco-av-pair ACS:CiscoSecure-Defined-ACL=#ACSACL#-IP-PERMIT_ALL_TRAFFIC-57f6b0d3

I can also see that the dACL exist on the firepower by for instance checking Edit Group Policy -> Advanced -> Traffic filter, where the access list name appears in the list of available access-list filters. But I haven't checked the content of the dACL since it's not in the running config, And I have not set up wireshark on this site to check the response from the ISE in detail.

So in my mind I seem to have the ISE covered and it looks like the Firepower is misbehaving. I'm running ISE 2.4.0.357 Patch 7,12 (yes it is time for an upgrade) and Firepower 6.6.4 (build 59). According to the support-matrix this combo should work?

Any tips or is there something obvious I have missed?

Erik

[Milos_Jovanovic]

Hi @erik.hammervold,

You can try to display dACL directly from CLI by using 'show access-list #ACSACL#-IP-PERMIT_ALL_TRAFFIC-57f6b0d3'. Since this is dACL, it is not stored in running-config, but it will be visible with 'show access-list'.

You can also try with 'debug radius', to see what is going on on FTD and whether FTD is accepting your dACL.

It is quite possible that something is wrong with your dACL, and FTD can't accept it, so I would go once more to validate dACL content. I would also try to simplify dACL at the begining with just one permit or deny statement, untill everything works, and then put inside what is required.

BR,

Milos

[Rob Ingram · Accepted solution]

@erik.hammervold 

So on the output of show vpn-sessiondb detail anyconnect - under the SSL Tunnel, the DACL is not applied under the "Filter Name" section?

On the FTD, if you run debug aaa radius do you see the response from ISE for a CoA? Immediately after receiving a CoA response, the debugs should confirm processing the Dynamic ACL.

If not perhaps check Dynamic Authorisation is enabled under the RADIUS Server Group object on the FMC.

[erik.hammervold]

Thanks for swift replies.

Seems like the problem lies in the Dynamic Authorization not enabled for this customer. Hopefully this is the only piece missing.

Can't implement the change today, but will test this next week.

[Milos_Jovanovic]

Dynamic A|uthorization is not required when using dACL.

Upon successfull authentication, authorization steps in, and, as part of authorization (and remember that authentication and authorization are one process in RADIUS), dACL is returned toi ASA, along with any other attributes. In this case NAD (ASA/FTD) is initiating RADIUS communication, and expecting reply (over UDP/1645 or UDP/1812).

Dynamic Authorization is used for CoA - when AAA server wants to initiate re-atuhorization of the endpoint, and in such case, AAA initiates RADIUS communication that NAD never initiated (usually ove UDP/1700). Most frequent use case for Dynamic Authorization is posture assessment - initially AAA knows one information about endpoint state assigning it one authorization profile (e.g. VLAN or dACL), and after posturing it knows different information and it triggers re-authorization which assign different profile (e.g. different VLAN or dACL).

I don't think Dynamic Authorization would help you here.

BR,

Milos

[erik.hammervold]

Aha.. So.. Back to the drawingboard again then.

I do not have the "Filter Name" section at all in the SSL-Tunnel section?

show vpn-sessiondb detail anyconnect 

SSL-Tunnel:
Tunnel ID : 7767.2
Assigned IP : xxxxxxx Public IP : xxxxxxx
Encryption : xxxxxxx Hashing : xxxxxxx
Ciphersuite : xxxxxxx
Encapsulation: xxxxxxx TCP Src Port : xxxxxxx
TCP Dst Port : 443 Auth Mode : userPassword
Idle Time Out: 30 Minutes Idle TO Left : 29 Minutes
Client OS : Windows
Client Type : SSL VPN Client
Client Ver : Cisco AnyConnect VPN Agent for Windows 4.9.04053
Bytes Tx : 8886 Bytes Rx : 1963
Pkts Tx : 6 Pkts Rx : 24
Pkts Tx Drop : 0 Pkts Rx Drop : 0

DTLS-Tunnel:
Tunnel ID : 7767.3
Assigned IP : xxx.xxx.xxx.yy Public IP : xyz.xyz.xyz.xyz.

Encryption : xxxxxxx Hashing : xxxxxxx
Ciphersuite : xxxxxxx
Encapsulation: xxxxxxx Src Port : xxxxxxx
UDP Dst Port : 443 Auth Mode : userPassword
Idle Time Out: 30 Minutes Idle TO Left : 29 Minutes
Client OS : Windows
Client Type : DTLS VPN Client
Client Ver : Cisco AnyConnect VPN Agent for Windows 4.9.04053
Bytes Tx : 2524 Bytes Rx : 2996
Pkts Tx : 18 Pkts Rx : 39
Pkts Tx Drop : 0 Pkts Rx Drop : 0

[Milos_Jovanovic]

This means that your dACL is most likely not accepted by ASA/FTD.

Have you attempted already to simplify dACL on ISE side? If not, try add one simple statement (like 'permit ip vpn_pool vpn_pool_mask host 1.1.1.1'), and repeat test.

If that doesn't help, try enabling following debugs:

debug radius

debug radius all

debug webvpn anyconnect 255

After that, try again to reproduce the issue, and look through logs.

BR,

Milos

[erik.hammervold]

Hi

Did a single line "permit ip any any" acl which did not help.

Will do another round of troubleshooting and debug later.

Thanx som far.