In this post I have the pleasure of talking about a project
that I’ve been working on for a while, as well as one of my all-time favourite
networking tools - Wireshark! For those that don’t know, Wireshark (originally
named Ethereal) is a packet sniffer program that decodes hundreds of networking
protocols for your viewing pleasure. I’ve been using Wireshark for
about 10 years now, and am extremely appreciative of all of the people that have worked to build and maintain the product over the years. The other amazing thing
about Wireshark is that it’s free software and works across all the major OS
platforms. So if you haven’t used it before, I suggest you use this as an
opportunity to download it and give it a try.
As an IT professional working on Lync / Skype for Business, what can Wireshark do
for you? Well, it can do quite a few things: I personally use it all the time
for troubleshooting connection issues, networking problems, certificate negotiation,
and other protocol issues. When I started using Wireshark with Lync / Skype for Business I found
that some protocols are not decoded properly by Wireshark, which made me sad. For
example, STUN (Simple Traversal Utilities for NAT) is a protocol used
extensively with Lync / Skype for Business is only partially decoded by Wireshark.
Example:
So why can’t Wireshark decode these STUN messages properly?
The answer to this is that Microsoft has made additions to the base IETF
standards which are not recognised by Wireshark. The good news is that Microsoft
documented these extensions and released them to the world. Some examples of
these documents can be found here:
Microsoft Protocol
Documentation:
- Microsoft Turn Bandwidth Management Extensions [MS-TURNBWM]
- Microsoft TURN Extensions [MS-TURN]
- Real Time Protocol Extensions [MS-RTP]
- RTP for Application Sharing Format Extensions [MS-RTASPF]
- RTP DTMF Extensions [MS-RTPDT]
- Interactive Connectivity Establishment (ICE) 2.0 BandwidthManagement Extensions [MS-ICE2BWM]
These
documents that are provided by Microsoft extend the base level standards that were
originally written by the Internet Engineering Task Force (IETF). Here are some
examples of these specifications:
IETF Protocol
Documentation:
Lync / Skype for Business Wireshark Plugin
Armed with the information available in the Microsoft’s
Office Protocol documents, RFCs, and a healthy dose of reverse engineering, I
was able to put together a plugin for Wireshark that made packet captures taken
on an Edge server readable. Below is an example of a packet capture taken on
an Edge server:
So without further ado, I give you The Lync / Skype for Business Wireshark
Plugin:
1.00 Initial Release:
- This Wireshark plugin is designed to dissect Lync AV Edge and Internal Edge AV traffic. Captures can be taken on the Edge server (Capturing AV Edge External traffic, and Internal Interface traffic), or it can also be used on the client side for decoding STUN and RTP/RTCP traffic.
- This Wireshark plugin dissects STUN/TURN traffic on Microsoft Lync Edge port 3478 (STUN, RTCP, RTP)
- This Wireshark plugin dissects traffic on Microsoft Lync Edge port 443 (STUN, RTCP, RTP)
- This Wireshark plugin dissects dynamically assigned RTP and RTCP traffic by using ports allocated in STUN requests.
- Dissector can be turned on/off within Wireshark Preferences. (Edit->Preferences->Protocols->LYNC_SKYPE_PLUGIN)
- Port numbers can be changed within Wireshark Preferences. (Edit->Preferences->Protocols->LYNC_SKYPE_PLUGIN)
- If you enter “lync_skype_plugin” in the Filter bar, only the traffic that is being decoded by the Lync Plugin will be displayed.
2.00 Wireshark 2.0 update:
- Some updates to work with Wireshark 2.0+
- Changed the naming of the plugin to LYNC_SKYPE_PLUGIN.
- Big updates to RTP and STUN classification to fix detection issues.
- Added TLS pass-through to the Wireshark default SSL dissector for Hello, Handshaking, and Application data. So now you can have the plugin running all the time and still troubleshoot TLS handshaking issues on port 443. This also makes the plugin better for client side testing.
- Corrected some issues with decoding 0x0013 Data Attribute encapsulated data.
- The decoding of port 443 can have false positive matches for different packet types. The amount of false positive in this version of the plugin has been greatly decreased.
- Widened the scope of RTP port classification from 1024-59999 (which was limited for Edge use) to 1024-65535. This makes the plugin work better when testing client side connections.
- And much more!
Available on the TechNet Gallery:
DOWNLOAD HERE
Note: The Lync Wireshark
Plugin by default will take over the dissection of UDP port 3478 and TCP port
443. You can turn these off in the plugin settings found under Edit->Preferences…->Protocols->LYNC_SKYPE_PLUGIN.
Feedback
It’s a complex balancing act decoding multiple protocols
that are multiplexed on the same port numbers. So there may be cases where you
run into something I haven’t seen before that may cause an error in the decode. If
you have an issue with the Plugin not decoding something correctly, or LUA
errors with your captures, please email me (mylynclab <at> gmail <dot>
com) an example of the capture (ie. a Wireshark pcap file) and tell me the
packet number where you had the error. I will endeavour to maintain the plugin
and correct issues that people might find.
Known Issues / Limitations:
- The plugin currently doesn't decode X-Address data for IPv6 packets. I don't have a capture of this to test on at the moment. If someone would like to supply one I can add the functionality.
- Plugin does not (yet) include full decoding of data encapsulated in 0x0013 data attributes.
Installation of Plugin
Installing the plugin could not be simpler. You simply take
the plugin file (Lync-Skype4B-Plugin2.00.lua) and put it in the following directory:
"C:\Program
Files\Wireshark\plugins\<wireshark version number>\"
After this, whenever you open Wireshark, this plugin will
also be used to decode protocols.
Example:
Plugin Settings
The plugin has some variables that can be set to change what
is getting decoded. The settings are accessed through Edit->Preferences…->Protocols->LYNC_SKYPE_PLUGIN. By default
all decoding is enabled (ie. UDP port 3578, TCP port 443, and dynamically
assigned RTP ports).
Plugin Settings:
Setting
|
Purpose
|
Decode UDP Port (Default 3478)
|
Port 3478 is the standard port used for STUN protocol on the Lync
Edge and Lync Front End servers.
|
Decode TCP Internal Port (Default 443)
|
Port 443 is the standard port used by Internal Edge services. The
Access Edge port gets sent STUN messaging on this port. Use this setting to
enable or disable the plugin from decoding traffic on this port.
|
Decode TCP External Port (Default 443)
|
Port 443 is the standard port used by Internal Edge services. This
will always be 443, however, it’s a variable for if something changes in the
future. Use this setting to enable or disable the plugin from decoding
traffic on this port.
|
Decode 1024-65535 Dynamic Ports
|
The 1024-65535 dynamic ports are the ports used by Servers and
Clients for RTP connections. By turning this setting on, the Plugin will look
in STUN messages for RTP ports that are being negotiated during session
establishment and add these ports to the decode.
|
UDP Port (Default 3478)
|
This port in theory should always be 3478. However, if you would like
to change this port number you can.
|
TCP Internal Port (Default 443)
|
The TCP decode ports have been broken into separate Internal and
External settings. This is for when you are capturing on an Edge server that
has a different port than 443 configured for the External AV edge. By default
internal and external AV (TCP STUN, RTP, RTCP) traffic will be on port 443.
|
TCP External AV Port (Default 443)
|
|
Show original Wireshark Dissection Tree (Default False)
|
When you are running the Lync Wireshark Plugin it will override the
original Wireshark decode for the ports that have been selected above.
If you would like to also see how Wireshark would decode the packets,
you can tick this box and the original default Wireshark decode will be
displayed in the tree item above the plugin decode.
|
Decode As...
The plugin by default will listen on port TCP 443 and UDP 3478 for traffic, this will capture traffic that is sent to Edge (and other) servers. However, if you make peer-to-peer calls between clients or phones the ports used may fall into the media port ranges which are not captured by default. If you have captured traffic on different ports that you would like to decode using the plugin, simply right click on the packet in Wireshark window and select "Decode As..." then set the Current protocol to LYNC_SKYPE_PLUGIN and it will decode the traffic with the plugin. Here is an example:
More Details on How Lync Edge protocols Work
There was a great blog post written back in the 2010 about
OCS that talks in some depth about how the STUN and TURN protocols are used by
Lync. So if you would like more of an overview of the protocols have a read of
this post.
Alternative Software
Microsoft also has their version of Wireshark that they call
Network Monitor. They also have a Parser pack for Lync that will decode STUN and RTP messages. Here is where you can get Network Monitor and the Lync parser
pack:
Note: Network Monitor
does not decode TCP (443) STUN/RTP messages and limited STUN attributes.
The Wrap Up
In this post we have travelled to tech town via the Metro (which recently had it’s name
changed to something that I can never seem to remember). The outlook from the windows of the train carriage were amazing, with vistas as far as the eye could see. When
we passed through the gates of the city
we were given the bill by the conductor
which, as it turns out, was free for onedrive
only. The word around town was that
there was a publisher that excelled at Lync projects. We tried
to gain access to him and see if he
would sharepoint his wisdom with us. After
much looking, we finally found him and he cryptically told us that the infoPath to enlightenment was perhaps
closer than we knew, and that we already had the powerpoint to realise this if we looked deep enough within
ourselves. The trip allowed us to plug back in to our natural surroundings and
be at onenote with nature. I hope you
had as much fun as I did... Oh dear, it seems I have “Jumped the Wireshark” with the puns on this wrap up…
J
ROFL - "Jumped the Wireshark"
ReplyDeleteI was STUNed at your wrap up..
Really brilliant, thanks
ReplyDeleteNice!! Where do you find the time to write all these great tools!?
ReplyDeleteIt was a nightmare to inspect TURN/STUN traffic in Wireshark until your great parser has come into play!! Many thanks for sharing
ReplyDeleteGreat plugin!! Thanks for doing this as wireshark is always my goto!
ReplyDelete