Case of the Tired Firewall

Case of the Tired Firewall

Have you ever had a nightmare where you are being chased and you can't just seem to run away fast enough? No? Well, maybe you've tried running through snow up to your knees or swimming while wearing jeans. All of those examples point to situations that feel like something isn't quite right. Cases where there could be better performance if only something was changed or improved. Sometimes this same thing happens to network devices. In this example, it's the case of the tired firewall. Problem It was a typical day in the office with users milling about drinking coffee, others happily working, and some furiously pecking at their keyboards with deadlines looming. For a small segment of users, though, things weren't normal. They were staring at their monitors with looks of puzzlement and confusion. Instead of working on their latest application update they were running tests with varying and unusual results. They found several symptoms, but were unable to pinpoint the root...
Read More

Case of the Rogue Server

Several hundred users lost network connectivity. They went down randomly, one by one, and over a short period of time. Some users had intermittent connectivity. All of the network devices were online and functional.  Users were roaming the halls and getting bored. This called for a packet capture, but with clients offline it had to be done on a network switch. In this instance, the capture was performed at the distribution switch on the layer 3 VLAN. It revealed clients frantically trying to connect but being rejected, dropped, and ignored. With everything down, something had to be done. The L3 VLAN was rebuilt and port security was removed. Nothing worked. An analyst at one point decided to clear the arp table. It helped momentarily, and then things fell back into disarray. That was the first real clue, though.   Viewing the ARP table showed the same MAC for several IPs including the client switch IPs. This MAC belonged to a device not managed by...
Read More
Become a Certified Wire Shark (WCNA)

Become a Certified Wire Shark (WCNA)

I recently sat for the Wireshark Certified Network Analyst (WCNA) certification again. This will be the second time I have taken it and the second time I have passed. I have taken several various networking certification exams, networked with people who have sat for others, and read about many more. Keeping all of that in mind, I think this is one of the most straightforward certification tests I have seen. Laura Chappell, Gerald Combs, and the team have done a great job with the books and preparation materials. If you're wondering if the exam is right for you, please continue.   Who should test? Network Admins If you are a network admin or analyst in any capacity then this certification will add to your resume and give you an edge over your peers. More than that, it will teach you about the protocols and applications that traverse your network and their expected behaviors. How can you architect and maintain a road if you don't...
Read More

Rename Files to WS File Set Format

Using file sets in Wireshark is a great feature. It allows for quickly navigating between smaller files instead of experiencing sluggish performance when analyzing one large file. However, there are times when packet captures were taken using a system other than Wireshark (such as TCPDump or Dumpcap). Other times someone else performs the captures and uses a different naming convention. Either way, there are times when it would be nice to convert these names into Wireshark's file set naming convention. For a full write-up on the function and naming convention, please see Wireshark's documentation here. To get started renaming files, please see below. Using Windows PowerShell: Create a folder where you want to rename files Create a new powershell script file with .ps1 extension (i.e. rename.ps1) Use the following script: $capname = Read-Host -Prompt "What is the new file name?" $i=1 dir *.*cap* | %{Rename-Item $_ -NewName ($capname + '_{0:D5}{1}' -f $i++,$_.Extension)} dir *.*cap* | Rename-Item -NewName...
Read More

Case Study: Capture at Both Ends

While the general rule of thumb is to capture at the client, or at least start there, sometimes it's necessary to take captures at both ends of a connection. The client perspective will allow you to view the problem as it is seen from the client. The server perspective might show the same thing. Or, in some cases like this one, it will provide the reason for the problem. The problem was that a webpage wouldn't load. There were various errors and no real indication of the problem. While SSL was suspected, there was no proof. So, we started with a capture at the client. From the client, the capture reveals it sent a TLSv1.2 Client Hello as expected. However, it then abruptly ends with a FIN with no server hello. Versions and ciphers were compared in the settings, but everything matched. More data was required. Another capture point was setup on the server. Immediately, the problem was revealed. The server received a...
Read More
TCP Performance Options

TCP Performance Options

In order to understand application performance across the network, we first have to understand the basic mechanisms. In this case that foundation is built on TCP, and, more specifically, the built-in TCP Performance Options. There are many things that can be done in an application to improve performance. There are also several options from a network perspective, and more still in the operating systems. However, these all rely on the underlying protocol. The Warm Up This blog can serve as a warm up to understanding TCP performance. But, it is still a high-level overview and based on my knowledge and experience. So, for other perspectives I have included some other blog links below in the "Other References" section. These are blogs from some experts in the field and I highly recommend reviewing their content and subscribing to them as well. Nothing beats going straight to the source; however, so I've also included some of the RFCs pertaining to TCP performance in the...
Read More
Performing a Capture

Performing a Capture

Start the Capture Now that you've decided where to capture, and you've prepared your interfaces and filters, you are ready to perform the capture. All you have to do at this point is hit the start button or double-click the interface in the list. There are usually multiple interfaces listed, so make sure you know which one you are wanting to use. Generally, this may be indicated by a small moving graph to the right of the device name indicating there is traffic present (the screen shot below currently show no traffic as I was in a lull). With Wireshark and some other utilities you also have the option to capture from multiple interfaces at once. Once the process is started, Wireshark uses the WinPcap driver to collect the packets from your network card and then displays them on-screen (if you haven't disabled that option for performance reasons). You will see columns and rows of numbers, letters, and words rapidly scrolling across...
Read More

Everyday Carry (EDC)

You may have heard the term "Every Day Carry (EDC)" from self-defense or survival circles. That is where I first heard it. As a tech guy, I think this same term can be applied to the gear we techies carry on a daily basis. So, I wanted to provide a quick list of the things I carry daily to/from work and elsewhere. These may not help you survive a zombie apocalypse (whatever that is), nuclear fallout, or a foreign invasion, but they should help make your day-to-day life a little easier. Feel free to comment on this post with things you carry, suggestions, alternatives, etc. I intend to make this list a little more fluid that will update as I change gear and as technology changes, so check back now and then.  ...
Read More
Preparing for the Capture

Preparing for the Capture

Packet captures give us a very detailed and in-depth look at network traffic. They can be used to establish baselines, discover network devices, diagnose application and performance issues, or identify security threats. The previous post described what packets are and their function at a high level. It also gave an overview of the process used to capture them. Once you have identified your purpose for performing a capture, you can begin preparing for it. Caution: This is where things get technical pretty fast. A good knowledge of basic networking concepts will help from this point forward. This post will also be a little lengthier. Preparing for a capture follows the same basic process regardless of the purpose, albeit a few tweaks here and there: Select the capture point(s) Choose the capture method Apply the appropriate filter(s) and configurationPost-prep actions Begin the capture Perform the task to generate target traffic if...
Read More
Capturing Light

Capturing Light

How do you go about catching the one of the fastest things known to man (light) at a specific point in time with pinpoint accuracy over and over again? With a little patience and your network card, of course! This post is an introduction to the process of capturing network traffic (aka "sniffing" or "tracing"). With most of my blog being dedicated to network performance analysis, a post like this is foundational, and will help you understand the basics moving forward if you are new to "sniffing the wire". Networks range in size from small home networks with 1 PC to global corporations with many users and data centers, to the largest network (or collection of networks depending upon your definition) of them all, the Internet. While size, speed, design, and costs may vary, they all use the same signals to communicate. These signals may take the form of electricity (ethernet cables), light (fiber), and radio waves (wireless) across varying mediums. These...
Read More
12