I got complains from a customer who wasn’t able to configure 3DES or AES encryption for a VPN tunnel. Sounds familiar with a problem I had a couple of weeks ago. So I gave the customer the advice to upgrade and activate the VPN-3DES-AES feature. He tried but that didn’t solve this problem.
I remotely logged in and checked the software he was using. I noticed he was using the image asa832-npe-k8.bin. Problem found!!!
NPE stands for No Payload Encryption. For export to some countries, payload encryption cannot be enabled on the Cisco ASA 5500 series. For version 8.3(2), you can now install a No Payload Encryption image (asa832-npe-k8.bin).
Features that are disabled in the No Payload Encryption image include:
If you attempt to install a Strong Encryption (3DES/AES) license, you see the following warning:
WARNING: Strong encryption types have been disabled in this image; the VPN-3DES-AES license option has been ignored.
I replaced the software image with the regular image and the problem was solved.
I had to troubleshoot a Cisco ASA today, where the client wasn’t able to connect to the management web interface anymore via https. The customer didn’t install ASDM locally, but always starts the Java-based version.
After upgrading the Cisco ASA to software version 8.2(1) and a reboot, the client wasn’t able to connect to the web interface anymore. I was able to connect to the firewall with my locally installed ASDM client, but I couldn’t access the web interface either.
While troubleshooting I first tried the basic settings, like management access-list, regenerate crypto keys and change the management port. All these options didn’t help, but the strange thing was that the web interface was working remotely.
While working with Mozilla I received the following error:
cannot communicate securely with peer: no common encryption algorithm(s).
In Google Chrome I receive the following error:
Error 113 (net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH): Unknown error.
And of course Internet Explorer didn’t gave any usable information. I started looking at the supported encryption algorithms within the firewall with a show version. I noticed that VPN-3DES-AES was disabled. The next step was the enable the VPN-3DES-AES ciphers. The upgrade license for this feature is available for free at http://www.cisco.com/go/license.
I activated the VPN-3DES-AES feature, but still wasn’t able to connect to the firewall with the web interface. I checked the SSL encryption used by the firewall.
fw01# show ssl
Accept connections using SSLv2, SSLv3 or TLSv1 and negotiate to SSLv3 or TLSv1
Start connections using SSLv3 and negotiate to SSLv3 or TLSv1
Enabled cipher order: des-sha1
Disabled ciphers: 3des-sha1 rc4-md5 rc4-sha1 aes128-sha1 aes256-sha1 null-sha1
No SSL trust-points configured
Certificate authentication is not enabled
The firewall still didn’t enable the ciphers supported in my browser. If the VPN-3DES-AES license isn’t installed, only the cipher des-sha1 is enabled by default. I added the correct ciphers with the following command:
fw01(config)# ssl encryption aes256-sha1 aes128-sha1 3des-sha1
After adding the command I was able to connect to the ASA with both the web interface and the ASDM.
While troubleshooting some performance issues with Citrix sessions between headquarters and sub locations, I decided to take a closer look at the PacketShaper. The PacketShaper is positioned at the headquarter and does outbound shaping to the sub locations. The PacketShaper is using older software (7.2x), which isn’t necessarily a problem.
I deleted the class for a specific location, created the class again and enabled traffic discovery for that class to check which protocols are used by the sub location.
Traffic Discovery: The PacketWise process of observing and creating traffic classes for all packets as they pass through the unit. This process compiles a list of the protocols and applications in use on a network, creating a traffic tree.
Traffic Discovery is working perfectly, because I see different protocols popping up under the sub locations class under which Citrix. In the past PacketShaper had the opportunity to discover the Published Applications or priority bit tagging used with Citrix. This gave you the opportunity to configure shaping parameters per published application.
Nowadays a lot of Citrix customers use Session Reliability. A major drawback of Session Reliability, in conjunction with a PacketShaper, is the encryption of the data stream. The encryption of the data stream prevents the PacketShaper from discovering the published applications or the priority bit tagging.
I first checked if this problem is solved by the latest software release (8.5 at the time of writing), but it isn’t. BlueCoat acknowledges the problem and describes it in this article. The article contains a link to another article about Manage Citrix Performance, which can be useful when using Citrix without Session Reliability.
Disabling Session Reliability isn’t an option for my troubleshooting, so I guess I have to find another way to troubleshoot the performance issues.