When I started at Novell almost twenty years ago I had the privilege of working on the LAN support team. Our job was to basically use tools like Network General’s Sniffer and LANalyzer to troubleshoot network communications. With help from great people like Earle Wells and Thom Kerby I quickly learned how to use these tools to get a whole lot done. Since those days a lot has happened and the network analyzer market has changed a lot, but most people’s favorite tool for doing packet traces and analysis is now the popular and very powerful Wireshark.

In this solution I want to take a few minutes and talk about how you can use this tool to capture packet traces and analyze packet traces for troubleshooting Novell ZENworks. The biggest obstacle in using packet traces for troubleshooting ZENworks is that communication is typically being sent using SSL encrypted HTTP requests. Fortunately, Wireshark provides the ability to decrypt SSL traffic as long as you have the server’s private key and are using compatible SSL ciphers.

Configuring Wireshark to decrypt your ZENworks SSL traffic

In order for you to analyze traces of ZENworks or other SSL traffic, you will need to configure Wireshark so that it can decrypt the SSL packets. To do this you need the following:

• The private key file and if applicable the password to decrypt the key file from the ZENworks or other SSL web server.

• The protocol embedded in SSL. For ZENworks this is typically HTTP.

• The port that the traffic is being sent on. For ZENworks this is typically TCP 443.

Once you have gathered this information you are ready to configure Wireshark. To do this:

1. Download and install Wireshark.

• From the menu bar, select Edit > Preferences.

• In the left pane of the preferences window, select Protocols > SSL.

• Click the Edit… button next to RSA Key list. This will display a dialog as shown below:
  

• In the IP address field enter the IP address of the Primary Server that the agent you are troubleshooting will be talking to.

• In the Port field enter the TCP port number that the Primary Server is configured to listen for SSL on. Typically this is port 443.

• In the Protocol field enter http.

• For the Key File, browse for the server’s private key.

• If necessary, enter the Password that allows Wireshark to decrypt the password.

• Click OK to save the change.

• Add additional keys if you have other Primary Servers that you want to add.

• Click OK twice to save the changes.

Wireshark should now be configured to decrypt the ZENworks traffic to the Primary Servers that you added. At this point you can select Capture > Interfaces and choose the Interface you want to capture. Of course, you Wireshark device will need to be plugged in to a mirrored port on the switch so that it can see the traffic coming from the device you are trying to troubleshoot. In the example provided here the trace was taken on the same device.

Reading a basic ZENworks trace

Once you have Wireshark configured to decrypt SSL traffic for your Primary Server then you should be able to trace traffic between a managed device and its Primary Server and you should be able to see the packets. One important note is that in order for you to trace SSL traffic Wireshark must see the SSL handshake. This may mean restarting the machine and tracing it from boot-up (for instance if you want to trace the login process) or initiating a refresh of the agent to establish the connection.

In the video below I show you how to analyze a sample ZENworks trace that shows what happens during a standard refresh of a managed device. In future cool solutions I expect to use a similar approach to show you how to troubleshoot common problems that we see or better understand how some of the ZENworks capabilities are implemented.

A word about cipher suites and SSL decryption

If you have a concern about people being able to do this kind of decryption, you may want to modify the cipher suites that ZENworks allows. If you remove the non-Diffie-Hellman ciphers (those that contain DH or DHE) from the ZENworks server configuration then the Diffie-Hellman key exchange will be used which prevents Wireshark from being able to use its SSL decryption capabilities. Likewise if your server is configured to use Diffie-Hellman ciphers and you want Wireshark to be able to decrypt your traffic you may need to disable the use of Diffie-Hellman ciphers. For ZENworks and other Tomcat based applications you control the cipher suites by editing the ciphers parameter in the server.xml file.

Decoding LDAP SSL Traffic

If you are trying to troubleshoot problems with authentication you may need to see the backend communication between the ZENworks server and the LDAP server. To do this in a trace you would need to obtain the LDAP server’s private key and add an additional SSL RSA key that decodes the LDAP protocol for your LDAP server’s IP address using the LDAP server’s private key. If you are unable to obtain this then you will most likely need to work with your directory administrator to enable LDAP debug logging on the LDAP server as you won’t be able to view the backend traffic.