Introduction
Just in case anybody was thinking ‘wow, this guy must have a cushy job, only three trouble tickets over the last 18 months’, then think again. The purpose of these trouble ticket posts is to write about those issues that don’t occur every day, the crafty quirks that have you scratching your head. In this case, I was witnessing something with the Cisco Secure Desktop feature that didn’t make sense and was frustrating to say the least.
Cisco Secure Desktop
For those not in the know, Cisco Secure Desktop (CSD) is a feature of the Cisco ASA platform that allows remote access VPN clients to go through a number of health checks before being allowed to connect. In the scenario discussed here, I had configured a couple of client certificate checks and wanted to add a third for a specific client type.
Diagram
The diagram above shows the third certificate check added at the bottom right. If this third check fails, the client is denied login.
Problem
When I saved the changes, everything looked as it should. The policy in the diagram above is not saved in the normal configuration file on the ASA but in this file: ‘flash:/sdesktop/data.xml’. As you can see from the snippet below, immediately after entering the third certificate check, the GUI and CLI agree on the configuration (certain details changed\removed):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
<multilocation> <sequence> <start> <choose type="cert_check"> <when label="Success" test="cert_check" arg1="XXX" arg2="XXX" arg3="XXX"> <location name="XYZ" /> </when> <otherwise label="Failure"> <choose type="cert_check"> <when label="Success" test="cert_check" arg1="YYY" arg2="YYY" arg3="YYY"> <location name="XYZ" /> </when> <otherwise label="Failure"> <choose type="cert_check"> <when label="Success" test="cert_check" arg1="ZZZ" arg2="ZZZ" arg3="ZZZ"> <location name="XYZ" /> </when> <otherwise label="Failure"> <denied /> </otherwise> </choose> </otherwise> </choose> </otherwise> </choose> </start> </sequence> </multilocation> <location name="XYZ"> |
The problem reared it’s ugly head when I closed ASDM and reloaded it. The XML file always shows correctly what the ASA is doing, but ASDM was now missing that third check in the GUI so now it appeared it was only carrying out the original certificate checks. That meant that to delete the third check, or add yet another check, I would need to hack the XML file.
Troubleshooting steps
I tried reloading the ASA. That made the GUI update to reflect the current XML file, but again, as soon as I made any changes and reloaded ASDM, the GUI would revert back to the two certificate check, regardless of what other checks I added. It was as if there was a cache somewhere.
I upgraded CSD to the latest version and still no joy. At that time, I got Cisco TAC involved. The person who I was dealing with was helpful and took all the details so he could lab it up. At first he reported he couldn’t replicate the issue but a few days later got back to me to report it was occurring but intermittently.
He requested some Java debug logs, which I duly gave and then waited for about a week while he escalated it to the development team.
Workaround
Finally, he came back to me to advise that this was being listed as a new bug:
CSCuh08360
Lucky me, I got my first bug listed. Something tells me it won’t be my last. There is a better workaround than rebooting the ASA each time though:
|
1 2 3 |
ASA(config)#webvpn ASA(config-webvpn)#no csd enable ASA(config-webvpn)#csd enable |
Summary
Basically, disabling and re-enabling CSD re-syncs the ASDM with the XML file, so until the bug is fixed, if you see this issue, I’d suggest doing this workaround before you make any changes to your CSD policies. FYI, I was using version 1.7 of Java and apparently 1.6 doesn’t have the same problem. So, to manage your firewall security device, feel free to use a less secure Java client. Sigh…
Till the next time.