| Follow me on:

Cisco ASA: web interface not working

December 14th, 2010 | 1 Comment

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.

AutoQos error while generating commands

December 2nd, 2010 | 1 Comment

First of all, the post isn’t about explaining QoS. Configuring AutoQos on Cisco switches should be very easy. At least, that is what all the Cisco documentation tells you. I always thought that the statements about configuration AutoQos were true, but a few days ago I would disagree.

I was configuring multiple switches, Cisco Catalyst 2960-24PC-L switches to be more precise. The switches are configured with a default template, which is generated according the needs of the customer. I uploaded the most recent software into the switches, which is 12.2(55)SE. The customer is going to use an Avaya IP telephony environment, so I tried to apply the appropriate AutoQos command to an interface. After applying the command, I received the following error:

AutoQoS Error while generating commands on Gi0/2

The switches didn’t have any QoS configuration before applying the command. Searching multiple forums didn’t gave me a valid solution. I did my own research and found an incompatibility with the configuration mode exclusion command, like shown below:

configuration mode exclusive auto expire 500 lock-show config-wait 5 retry-wait 5

I removed the configuration mode exclusion command and the AutoQos commands can be implemented without errors. I tried to find why it isn’t possible to apply the AutoQos commands while the configuration mode exclusive command is enabled.

I guess the problem is that the configuration mode exclusive commands prevents other users or the auto-generation of commands to be executed. When applying the AutoQos commands, the commands are executed by the router / switch and not by the user who locked the cli.

Citrix NetScaler: Protocol Driver Error

April 20th, 2010 | 1 Comment

Today I have been troubleshooting a Citrix NetScaler configuration, where some clients received the Protocol Driver Error message when executing a published application. This error message is mostly related to a wrong configuration of the Security Ticket Authorities (STA’s). I spent a lot of time troubleshooting this issue and focused on the STA configuration. I have been deleting, adding and modifying multiple STA’s to the configuration of the NetScaler without any luck. I checked the configuration of the firewall, but this wasn’t the problem either.

I decided to go back to basic and just added one STA to the Virtual Server and the STA service group used by the Web Interface. I was able to login with that STA server, but after a while I wasn’t able to login and received the Protocol Driver Error again.

While browsing through the NetScaler I noticed one thing. Every time I wasn’t able to login, there were 5 concurrent users already connected with the NetScaler. I did some more research on the internet and found the following article.

Reading the article, tells me that, by default, only 5 concurrent ICA sessions are possible through the NetScaler. I checked the license and the customer has a license for 50 SSL VPN connections, like shown below:

> show license
License status:
Web Logging: YES
Surge Protection: NO
Load Balancing: YES
Content Switching: YES
Cache Redirection: NO
Sure Connect: NO
Compression Control: NO
Delta Compression: NO
Priority Queuing: NO
SSL Offloading: YES
Global Server Load Balancing: NO
GSLB Proximity: NO
Http DoS Protection: NO
Dynamic Routing: YES
Content Filtering: YES
Integrated Caching: NO
SSL VPN: YES  (Maximum users = 50)
AAA: NO
OSPF Routing: NO
RIP Routing: NO
BGP Routing: NO
Rewrite: YES
IPv6 protocol translation: YES
Application Firewall: NO
Responder: YES
HTML Injection: NO
NetScaler Push: NO

I increased the default value to 50 with the following command:

> set aaa parameter -maxAAAUsers 50

From that point on I was able to start another ICA connection, while there were already 5 concurrent users connected. Now I have to wait and see if this actually solved the problem, but I guess it has.

I tried to increase the –maxAAAUsers value to a value higher than 50, but that isn’t possible as you can see.

> set aaa parameter -maxAAAUsers 100
ERROR: MaxAAAUsers value not allowed by license

RDP and Spooler system service

August 12th, 2008 | 1 Comment

My colleagues and I configure a Windows server from time-to-time. Mostly when we configure a server, it is a server which is placed in the DMZ zone, like an ISA Reverse Proxy or Citrix Secure Gateway. Recently I spoke with a colleague and we started discussing the running services under Windows.

After installing a Windows server with the default settings, I am stunned about all the different services which are running on the newly installed server. So most of the time, I stop a lot of these services and configure them to be started manually after a reboot. I do not only stop services from the Services MMC, but also settings on the network card, like Client for Microsoft Windows, File and Printer Sharing for Microsoft Windows, Registrar connection in DNS, LMHOST lookup and NetBIOS over TCP/IP.

Normally a server in the DMZ doesn’t have any printers connected, so I stop the Print Spooler service, but when connecting to the server with RDP the following Event logging shows up in the Event Viewer –> System log:

EventID: 1114

Source: TermServDevices

Type: Warning

Description: Error communicating with the Spooler system service. Open the Services snap-in and confirm that the Print Spooler service is running.

Looking at the Internet, there are different ways to stop is error from showing up in the Event viewer. All solutions are related to stopping the mapping of printers during the RDP log-in process. My colleague told me that he always uses a registry entry to disable the logging and guess what, this specific registry entry is shown below:

Registry folder: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd

Entry name: fEnablePrintRDR

Type: REG_DWORD

Value: 0×00000000 (0)

After adding this registry key the warning message in the Event Viewer won’t show up again.

ISA 2006 Authentication over HTTP

July 8th, 2008 | No Comments

I implemented different ISA 2006 Reverse Proxy servers in conjunction with Microsoft Exchange 2003 or Windows Exchange 2007.

Today I configured ISA 2006 with Exchange 2007. I configured the Reverse Proxy server as I did always. And the connection from outside the network works perfectly. On the internal Exchange server I configured Basic and Integrated Authentication on the OWA virtual directory. The problem is that internal users now automatically log in to their webmail box when entering the URL from the Exchange server.

This is not the desired configuration, because internal users should be able to open other people’s mailboxes by logging in as that user. The customer also has an ISA 2006 on the internal network for forwarding proxy purposes.

I decided to publish Exchange 2007 on the internal ISA 2006 server as well. The configuration should use Form Based Authentication (FBA) over HTTP. After configuring and trying the connection, the user can’t access the ISA logon page. In the logging you find that Authentication over HTTP isn’t allowed.

Error Code: 403 Forbidden. ISA Server is configured to block HTTP requests that require authentication. (12250)

This is a default setting in ISA 2006 which can be disable. To allow Authentication over HTTP go to the Listener configuration. Go to the Authentication tab and Select Advanced. In the next tab enable the option Allow client authentication over HTTP. This option enables the using FBA over HTTP.