Steven, Can you confirm the version of AnyConnect or NAM which fixed this issue in April? Is that 4.4 MR3 or is it specific to a NAM version which is bundled with one of the AnyConnect packages?
... View more
Thanks Steven, It seems like the biggest customer hardship that customers are running into is that the AnyConnect uninstaller doesn't remove it completely, it leaves evidence which is reused when a new installation is done, and this causes issues with the new Windows version all over again. Are there any plans on changing this behavior to completely remove all files associated to the installation so that this is less of an issue and preventing the customer from having to install another application to clean up what is seen as a "Cisco mess"?
... View more
Hi Paul, Yes there is a TAC case which resulted in opening a support case with Microsoft Premier to see what has changed and how NAM interacts with their supplicant as a result. SR is 682419950 V/R, Patrick Lloyd Security Solutions Architect CCIE R&S #39750, CISSP Cisco Security Solutions .:|:..:|:. Cisco Systems 732-516-5611
... View more
Hi Team, I've had the following inquiry posed from a customer: Does Cisco list supported Wi-Fi card/drivers that would be recommended for AnyConnect NAM? I believe the answer is "the list would be far to extensive and ever changing for us to maintain" but wanted to verify before informing the customer.
... View more
Hi team, I have a large NAM customer that I'm working with who has continually run into issues with the NAM client due to the changes that Microsoft makes regularly to how the networking drivers interact with the AnyConnect NAM client. The biggest issue they run into is that older versions of NAM are rolled back to, or that they can't upgrade devices in place as Microsoft moves to a deployment services model with a new service patch every month or so. When this occurs, they almost always hit a blue screen or bug with NAM. Right now they would just be happy with a work around of a clean uninstall script for NAM and all AnyConnect components, which does not exist - registry information continues to exist for AnyConnect which impacts the install and rolls back the version, causing a continual issue unless manual intervention is used. Is something like this being developed or does it currently exist? Is there any way to completely remove all NAM and AnyConnect components to ensure that a clean install will fix issues after upgrade? Are we working with Microsoft to better align with their upgrade models so that we don't have compatibility issues in the first place, so I can better assure the customer of our commitment to their success?
... View more
It should be noted that auto-update timeout 1 as you have it configured here can cause issues. In my deployment, ASA5506 running 18.104.22.168, when configuring a timeout so small I get "Syslog Error 201008: Disallowing New Connections". In addition, I use the following configuration for NameCheap.com:
auto-update server https://22.214.171.124/update?auto-update poll-period 30 3 1
auto-update server https://126.96.36.199/update?host=_MYASAHOSTNAME_&domain=_MYDOMAIN_&password=LONGANDCOMPLICATED source OUTSIDEINTERFACE no-verification
... View more
This document describes how to configure the Cisco Adaptive Security Appliance (ASA) Version 9.2 and above in order to posture VPN users against the Cisco Identity Services Engine (ISE) utilizing a natively installed AnyConnect client and Compliance Module.
Cisco recommends that you have knowledge of these topics:
Basic knowledge of ASA CLI configuration and Secure Socket Layer (SSL) VPN configuration
Basic knowledge of remote access VPN configuration on the ASA
Basic knowledge of ISE and posture services
Basic knowledge of AnyConnect
The information in this document is based on these software versions:
Cisco ASA software Versions 9.2.1 and later
Microsoft Windows Version 7 with Cisco AnyConnect Secure Mobility Client Version 4.2
Cisco ISE Version 2.0
Starting with Cisco ASA Version 9.2.1, support for RADIUS Change of Authorization (CoA) (RFC 5176) was added. This allows for posturing of VPN users against the Cisco ISE without the need for an IPN, and can be natively done with the Cisco AnyConnect Secure Mobility Client with AnyConnect Compliance Module. After a VPN user logs in, the ASA redirects web traffic to the ISE, where the user is provisioned with AnyConnect and its Compliance Module. AnyConnect then performs specific checks on the user machine in order to determine its compliance against a configured set of posture rules, such as Operating System (OS), patches, AntiVirus, Service, Application, or Registry rules.
The results of the posture validation are then sent to the ISE. If the machine is deemed complaint, then the ISE can send a RADIUS CoA to the ASA with the new set of authorization policies. After successful posture validation and CoA, the user is allowed access to the internal resources.
Network Diagram and Traffic Flow
Here is the traffic flow, as illustrated in the network diagram:
The remote user uses Cisco AnyConnect for VPN access to the ASA.The ASA sends a RADIUS Access-Request for that user to the ISE.
That request hits the default policy set with a policy named ASA_POSTURE on the ISE. As a result, the ASA_POSTURE authorization profile is returned. The ISE sends a RADIUS Access-Accept with two Cisco Attribute-Value pairs:
url-redirect-acl=redirect - this is the Access Control List (ACL) name that is defined locally on the ASA, which decides the traffic that should be redirected.
url-redirect= https://192.168.123.62:8443/guestportal/gateway?sessionId=xx&action=cpp - this is the URL to which the remote user should be redirected.
Tip: The Domain Name System (DNS) servers that are assigned to the VPN clients must be able to resolve the Fully Qualified Domain Name (FQDN) that is returned in the redirect URL, if the FQDN is used. If the VPN filters are configured in order to restrict access at the tunnel-group level, ensure that the client pool is able to access the ISE server on the configured port (TCP 8443 in this example).
The ASA sends a RADIUS Accounting-Request start packet and receives a response. This is needed in order to send all of the details in regards to the session to the ISE. These details include the session_id, external IP address of the VPN client, and the IP address of the ASA. The ISE uses the session_id in order to identify that session. The ASA also sends periodic interim account information, where the most important attribute is the Framed-IP-Address with the IP that is assigned to the client by the ASA (192.168.123.33 in this example).
When the traffic from the VPN user matches the locally-defined ACL (redirect), it is redirected to https://192.168.123.62:8443. Dependent upon the configuration, the ISE provisions the AnyConnect Posture Compliance Module.
After the agent is installed on the client machine, it automatically performs specific checks. In this example, it searches for the c:\watermark.txt file. It also sends a posture report to the ISE, which can include multiple exchanges with the use of SWISS protocol and ports TCP/UDP 8905 in order to access the ISE.
When the ISE receives the posture report from the agent, it processes the authorization rules once again. This time, the posture result is known and another rule is hit. It sends a RADIUS CoA packet:
If the user is compliant, then a Downloadable ACL (DACL) name that permits full access is sent (AuthZ rule ASA_COMPLIANT).
If the user is non-compliant, then a DACL name that permits limited access is sent (AuthZ rule ASA_NONCOMPLIANT).
Note: The RADIUS CoA is always confirmed; that is, the ASA sends a response to the ISE in order to confirm.
The ASA removes the redirection. If it does not have the DACLs cached, it must send an Access-Request in order to download them from the ISE. The specific DACL is attached to the VPN session.
The next time that the VPN user tries to access the web page, it can access all of the resources that are permitted by the DACL that is installed on the ASA. If the user is not compliant, only limited access is granted.
Note: This flow model differs from most scenarios that use RADIUS CoA. For wired/wireless 802.1x authentications, RADIUS CoA does not include any attributes. It only triggers the second authentication in which all attributes, such as DACL, are attached. For the ASA VPN posture, there is no second authentication. All of the attributes are returned in the RADIUS CoA. The VPN session is active and it is not possible to change most of the VPN user settings.
The ASA configuration is similar to that of a standard VPN configuration which utilizes AAA to authenticate the user. The following basic configurations are included in the configuration below:
An IP Pool to allocate an address to the user
Interface configurations of both the inside and outside interface
A definition of the AAA RADIUS server
WebVPN configuration for SSL VPN termination
Group Policy for the VPN session
A tunnel group used for the VPN session
More information on basic configuration of remote access VPN is available with the vpnsetup command.
ASA Configuration Example
! A local pool will need to be configured for clients which will be terminated on the ASA, providing them
! an IP address to use in their routing. This is a standard configuration for remote access VPN
ip local pool ISE_POOL 192.168.123.33-192.168.123.39 mask 255.255.254.0
! Outside interface to face the service provider through which clients will connect
ip address 10.87.2.244 255.255.254.0
! Inside interface, which will also be used to connect to the ISE server, as a radius server.
ip address 192.168.122.70 255.255.254.0
! Redirection ACL’s. Redirection ACL’s tell the ASA which traffic to permit to be redirected to the ISE
! server, triggering the posture assessment. Deny statements should be configured as the first lines,
! specifying the DNS, DHCP, ISE PSN, and ISE PAN servers. These servers will be denied from the
! redirection, allowing for traffic to hit these servers without triggering posture. This is desired to
! prevent a loop in logic, such that traffic to the PSN needs to be redirected, but is redirected continually
! rather than reaching the PSN.
! PSN in our example
access-list REDIRECT extended deny ip any host 192.168.123.62
! PAN in our example, not necessarily needed beyond testing
access-list REDIRECT extended deny ip any host 192.168.123.61
! DNS Server in our example
access-list REDIRECT extended deny ip any host 192.168.123.8
! Permit all other traffic to be redirected, triggering posture check
access-list REDIRECT extended permit ip any any
! Default route to our service provider for all traffic
route outside 0.0.0.0 0.0.0.0 10.87.2.1 1
! Configure the RADIUS AAA server. Options include interim accounting updates being sent every 3
! hours, and dynamic authorization to allow for a COA to be sent to the VPN client.
aaa-server ISE protocol radius
interim-accounting-update periodic 3
! Definition of the RADIUS AAA Server and it’s interface based location
aaa-server ISE (inside) host 192.168.123.62
! Definition of the HTTP server to allow for ASDM access to the device is required.
http server enable
http 10.87.2.0 255.255.254.0 outside
http 192.168.122.0 255.255.254.0 inside
! Enable the SSL VPN to connect via webvpn
anyconnect image disk0:/anyconnect-win-4.2.05015-k9.pkg 1
anyconnect image disk0:/anyconnect-win-4.1.06020-k9.pkg 2
! Configure the group policy with allowed connection means and DNS servers. The DNS servers defined
! in this section are important to ensure that we can reach the PSN when doing the redirection, as
! configured in the AnyConnect Configuration in ISE.
group-policy ISE_VPN internal
group-policy ISE_VPN attributes
dns-server value 192.168.123.8 10.87.3.78
! This username will do NOTHING in regards to posture. Remember that our authentication and
! authorization will be done through ISE as configured. The command “authorize-only” can be used in
! the aaa-server configuration if authentication should be done through a separate means. This
! username was purposely added for illustration and device administration.
username cisco password 3USUcOPFUiMCO4Jk encrypted
! Tunnel group definition for remote access
tunnel-group ISE_AAA type remote-access
tunnel-group ISE_AAA general-attributes
! Refer to the local pool created above
! Set authentication and authorization to the ISE Server defined above
! Set the accounting server to ISE for start-stop information
! Refer to the group policy created above
! If the group URL isn’t set in the webvpn attributes below, you may see an error in authentication
! where authentication never hits the ISE server, as it is using a default authentication method.
tunnel-group ISE_AAA webvpn-attributes
group-alias ISE_AAA enable
group-url https://10.87.2.244 enable
The ISE configuration consists of multiple parts.
The Dynamic Access Control Lists
These lists will be applied to traffic as it originally terminates on the ASA and the ASA reaches out via RADIUS to be authenticated and authorized. At least two Access lists will need to be created for this task:
A compliant access control list: This access control list allows for access to whatever resources the endpoint should be allowed access to in the case that it is given its full amount of access to the network. Typically this access control list with be “ permit ip any any ”, however can change depending on the needs of the endpoints once authorized.
A noncompliant access control list
This access control list allows for access to whatever resources the endpoint should be allowed when not authorized to the network. This is typically access to a remediation server which hosts resources for the endpoint to become compliant. In addition, DNS, DHCP, and the PSN are all recommended to be allowed to ensure that resolution for the remediation can occur. Typically, this access control list looks like the following:
! Policy Services Node
deny ip any host 192.168.123.62
! DNS Server
deny ip any host 192.168.123.8
! Internal network
deny ip any 192.168.122.0 0.0.1.255
! Permit access to only a DMZ based remediation server
permit ip 10.87.3.10
A redirection DACL is NOT needed on the ISE deployment or as part of the ISE configuration within the dynamic access control lists area. The redirection ACL is configured on the ASA and pushed down to the ASA via RADIUS to apply to the endpoint session, allowing for access to the PSN, DNS, Remediation Server, and similar resources.
The Authorization Profiles
Authorization profiles will be used to dynamically change the access the endpoint has based on its posture status, which will be configured in the Authorization Policies step below. Three authorization profiles will need to be created for each scenario of posture configuration:
The Unknown Posture Profile
The unknown posture profile is the default posture profile that every endpoint will hit when they first connect into the ASA for VPN termination. This is because ISE has not yet evaluated the posture of the endpoint, and still needs to connect to the compliance module to determine the state of the device, utilizing the checks which will be configured in later steps. Therefore, the unknown compliance profile sets the redirection ACL which is pushed to the ASA via RADIUS, and redirects the session to the Client Provisioning Portal. While this may seem counter-intuitive, if the posture is unknown and ISE is unable to determine what the posture of the endpoint is, this typically means that the Compliance module is not installed, or hasn’t responded to the call for a compliance check. If the compliance module is not installed on the endpoint, by redirecting the client to the client provisioning portal, it will be given the opportunity to download the compliance module and update the AnyConnect package currently installed to accommodate this request. If the compliance module is installed, this redirect will typically kick off the compliance check against the endpoint.
The Compliant Posture Profile
In the vast majority of cases, the compliant posture profile will be hit at some point within the posture evaluation, giving the endpoint full access as configured in the compliant access control list above. This is hit after the compliance check has completed, and the requirements configured for the endpoint have been met. This will typically take the form of the compliance module checking for compliance, once it is installed during the Unknown Posture Profile Phase. In this example, this profile will push a permit ip any any access list for the endpoint.
The Non-Compliant Posture Profile
The non-compliant posture profile is used for a client which is not compliant to the requirements which have been configured within Cisco ISE. The behavior of ISE in this manner is slightly counter intuitive to some system administrators, as during the countdown which is provided to remediate the non-compliant workstation, the endpoint remains in a redirection or unknown compliance state. Only after the countdown expires and an endpoint is not in compliance with the policy configured within ISE, will the session be put into a non-compliant state.
The Posture Requirements
Posture requirements are conditions configured by the ISE administrator to determine what a “compliant” endpoint is. These conditions take many forms, and for each form will have a different configuration syntax which will need to be populated. The conditions available within ISE 2.0 include the following:
AV Compound Condition
AS Compound Condition
Dictionary Simple Condition
Dictionary Compound Condition
Patch Management Condition
Disk Encryption Condition.
For more information on supported conditions for the type of endpoint and client, refer to the following link:
For this example, I’ll being a file condition to simply demonstrate the ability to look on the endpoint’s hard drive for a file which exists in a certain area.
The Remediation Action
The remediation allows for an automated or manual remediation of the non-compliant condition which the endpoint is currently under.
For remediation of files, this can be done by automatically uploading a file to the endpoint’s hard drive, to exist in the designated by the requirement, defined in the previous step.
For remediation actions such as AS and AV remediation, automatic remediation can be triggered by citing the AV or AS vendor from within ISE’s built in vendor list, update regularly through the Posture Feed Profile. This feed profile can be found in the Administration > System > Posture > Updates area. Automatic check and immediate updating can be done to populate these lists when need be.
For remediation actions such as Windows Update Remediations, Windows Update settings can even be changed in case the end user has disabled windows update on their endpoint.
The Client Provisioning Resources
The client provisioning resources work in conjunction with the authorization profile which redirects users with an unknown posture status to the client provisioning portal to download a profile and configuration for ISE and its compliance module. Four resources make up the client provisioning resources, which is found in Policy -> Policy Elements -> Results -> Client Provisioning -> Resources.
The AnyConnect Package: An operating system specific package which is uploaded to ISE through the “Add Agent Resources from Local Disk” context menu. For Windows systems this is the head end deployment PKG file directly off of CCO.
The ISE Posture Configuration File: This configuration file dictates the compliance settings to be used when the compliance module is started on the end user’s machine. This dictates configurations such as the length of time the user has to remediate a non-compliant machine, enables additional debug logs for compliance, and specifies the PSN to which the compliance module should reach out to. The “server name rules” field can be used to specify the domain which the compliance server should exist on, if the end machine will be connecting to multiple domains with overlapping IP addresses.
AnyConnect Configuration File
This configuration file determines the packages which should be installed on the user’s endpoint to do compliance or Log Collection, in the case of the DART bundle. Typically, VPN, Compliance, and DART are the main pieces which are required on the user’s endpoint.
In addition, the Compliance Configuration Profile within the ISE Posture drop down, AnyConnect update deferment, and whether the user should have their NAC client uninstalled are all referred to and configured in this area.
The Compliance Module Package
The AnyConnect Compliance Module file is the file which will be pushed down to the installed AnyConnect package to check compliance. This is pushed down to the Headend AnyConnect Deployment package which was added in the previous steps from CCO. However, this file is downloaded through the “Add Resources from Cisco Site”. Note that multiple versions of this file may exist, and the correct module should be added for the installed version of AnyConnect, otherwise a “Failed to download compliance package” error message may be observed. Where need be, this file can also be downloaded from the AnyConnect 4.x -> ISEComplianceModule area of CCO as well.
The Supplicant Provisioning Wizard
The Supplicant Provisioning Wizard is downloaded based on the operating systems which will be doing posture on the end user network. This Wizard is an agent which will deploy the AnyConnect and Compliance modules through a small download when a user in an unknown posture state due to not having AnyConnect is detected. This is triggered when the endpoint opens a web browser on an unknown compliance workstation to try to access the network, and is greeted by a client provisioning portal. This portal is hosted on the PSN, and is typically one of the few resources an unknown compliance workstation has access to, as per the DACL’s configured in the Authorization Profile configured previously.
Utilizing the requirements configured in previous steps, the posture policy is now configured to determine what a client requires to be in compliance with the ISE policy for posture. This configuration refers back to the requirement configured in Conditions, as well as the operating system and identity group, if applicable.
Once the endpoint has been evaluated utilizing the requirements, had the AnyConnect and Compliance modules installed via the resources, and had the modules configured with their respective profiles, the authorization profile is finally hit now that a result has been reported back to ISE. The Authorization policy will assign the proper results to compliant and non-compliant endpoints, as configured in the Authorization Profiles and DACLs configured in previous steps, or redirect the endpoint through a Redirection URL to the client provisioning portal for download of AnyConnect, the Compliance Module, and proper configuration files. Each of these authorization policies will refer to the session posture status as a condition, equaling compliant, non-compliant, or unknown.
Client Provisioning Policy
Once the AnyConnect configuration and Posture configuration are both configured, for the times in which the compliance module is not deployed and the endpoint needs to be redirected to the client provisioning portal, a policy needs to be configured referencing what resources need to be pushed down to the endpoint when the user hits the Start button. This start button will deploy the AnyConnect Client if needed, Compliance Module if needed, and Compliance configuration, all configured in previous steps.
This policy will be based on the operating system to which the client should be deployed, and will typically utilize the AnyConnect configuration, the Supplicant configuration wizard, and ISE Native Supplicant Provisioning Policy, all of which were either pre-populated, or configured in previous steps.
... View more
I'm not seeing the ability within the settings of the ISE hotspot portal to mask the characters of the access code required for successful authorization. I'm also not seeing this as an enhancement bug internally. I've tested on both 1.3 and 2.0 and can't find a setting which would change the behavior. Is this being considered as an enhancement, or am I overlooking a setting somewhere?
... View more
Hi Daniel, I personally haven't done this, but it is possible. The caveat that you ran into was you were using MSDP, a more common multicast feature, as opposed to Multicast Dynamic Tunnel (MDT). You would use the tunnel to do the import of the multicast routes into the require VRF. See the following documentation links showing how this would be done: http://www.cisco.com/c/en/us/td/docs/ios/ipmulti/configuration/guide/imc_mc_vpn_extranet.html#wp1085847 https://supportforums.cisco.com/discussion/10345651/route-leaking-multicast-vrf
... View more
Thanks for the question! This is actually a good one that I've encountered with a couple customers in the past, the tradeoff between a flood and prune type design, as opposed to the shared tree -> shortest path tree sequence. As per Cisco best practice, we are actively trying to get customers to implement sparse mode, going so far as to not support PIM dense mode in our data center products. And for good reason! The last thing you want is a chatty protocol within the data center which is flooding traffic out to receivers who may or may not be interested in it every 3 minutes. Instead, you're much better off having interested receivers join a stream, have your RP connect the interested senders and receivers, and then transition to the shortest path between source and destination. That being said, if you're studying for CCIE or looking to get experience in how multicast works, dense mode should at least be a lab exercise! Links for reference as to the difference in PIM modes: Dense Mode Operation: http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_pim_dense_rfrsh.pdf Pim Modes and explanation of each: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_53_se/configuration/guide/3750xscg/swmcast.html#wp1077051 A great slide deck to learn the operation of multicast: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=6633&backBtn=true Troubleshooting Multicast: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78578&backBtn=true Let me know if this is the answer you're looking for!
... View more
You could do most of this with SNMP, if you polled every 60 minutes or even kept the default of every 5 minutes, you could monitor 1, 2, 6, 7, 8, 9, 10, 11. 3 could be solved with IP SLA configured on the device and a responder on the opposite side, that could also be polled with SNMP. 4 and 5 are the more complicated because you're doing a calculation of traffic, so you would need to classify traffic into broadcast/multicast/unicast which you would have to do based on the destination address. I really don't think you could do this with the normal show commands. I'm thinking something like a SPAN session on the interface to a traffic analyzer would be the better bet.
... View more
Take a look at packetlife and their BGP cheat sheet to get mroe information on the BGP attributes, how they're communicated, and how to do path influencing: http://media.packetlife.net/media/library/1/BGP.pdf The Cisco BGP attributes page also tells of the specific Cisco proprietary attributes: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml
... View more
If your interface is a gigabit interface, it won't be able to send over that speed. You can set the speed or shape to a lower rate than the gigabit, but why would you shape to the maximum that your interface is going to support anyway? That being said, testing on a 2851, I can confirm that as of 12.4(24)T you can set the maximum shaping speed to 10,000,000,000 bits per second.
... View more